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PREFACE 


The  Center  for  Information  Systems  Research  (CISR)  is  a 
research  center  of  the  M.I.T.  Sloan  School  of  Management. 

It  consists  of  a,  group  of,  management  information  systems 
specialists,  including  faculty  members,  full-time  research 
staff,  and  student  research  assistants.  The  Center's  general 
research  thrust  is  to  devise  better  means  for  designing, 
implementing,  and  maintaining  application  software, 
information  systems,  and  decision  support  systems. 

% 

Within  the  context  of  the  research  effort  sponsored  by 
the  Naval  Electronics  Systems  Command  under  contract 
N00039-78-G-0160 , CISR  has  proposed  to  conduct  basic 
research  on  a systematic  approach  to  the  early  phases  of 
complex  systems  design.  The  main  goal  of  this  work  is  the 
development  of  a well-defined  methodology  to  fill  the  gap 
between  system  requirements  specification  and  detailed 
system  design. 

The  research  being  performed  under  this  contract  builds 
directly  upon  results  stemming  from  previous  research 
carried  out  under  contract  N00039-77-C-0255.  The  main 
results  of  that  work  include  a basic  scheme  for  modelling  a 
set  of  design  problem  requirements,  techniques  for 
decomposing  the  requirements  set  to  form  a design  structure, 
and  guidelines  for  using  the  methodology  developed  from 
experience  gained  in  testing  it  on  a specific,  realistic 
design  problem. 

The  present  study  aims  to  extend  and  enhance  the 
previous  work,  primarily  through  efforts  in  the  following 

areas: 


1)  additional  testing  of  both  the  basic  methodology, 
and  proposed  extensions,  through  application  to  other 
realistic  design  problems; 

2)  investigation  of  alternative  methods  for  effectively 
coupling  this  methodology  together  with  the  preceding 
and  following  activities  in  the  systems  analysis  and 
design  cycle; 

3)  extensions  of  the  earlier  representational  scheme  to 
allow  modelling  of  additional  design-relevant 
information; 


4)  development  of  appropriate  graph  decomposition 
techniques  and  software  support  tools  for  testing  out 
the  proposed  extensions. 


This  Document  relates  primarily  to  category  (1) 
above.  It  reports  the  results  of  the  application  of 
the  Systematic  Design  Methodology  to  the  developement 
of  a design  architecture  for  a new  Institute-wide 
Budgeting  System  for  M.I.T.  Various  techniques  and 
methods  discussed  in  earlier  reports  of  this  series 
were  used  in  the  application  study.  This  report 
discusses  both  the  development  of  the  system's 
architecture  per  se,  as  well  as  the  ways  in  which  the 
methodology  was  used  by  the  designers,  and  the  lessons 
learned  in  the  study. 


EXECUTIVE  SUMMARY 


X 

Recent  research  in  software  engineering  and  systems 
design  has  shown  that  many  of  the  problems  of  cost,  reli- 
ability, and  modifiability  of  complex  software  systems 
arise  because  of  fundamental  design  errors  and  oversights 
made  during  the  early  stages  of  systems  design.  While 
a number  of  other  software  researchers  and  practitioners 
have  developed  new  design  methodologies  recently,  none 
of  them  directly  address  such  preliminary  design  issues. 
The  Systematic  Design  Methodology,  a new  approach  being 
developed  by  researchers  at  the  M.I.T.  Sloan  School  of 
Management,  consists  of  a set  of  concepts,  analysis 
techniques,  and  tools  to  assist  a software  architect  in 
synthesizing  a design  framework  early  in  the  design 
process.  This  report  describes  and  analyzes  the  results 
of  an  application  of  the  Systematic  Design  Methodology 
to  the  architectural  design  of  an  "application"  software 
system  - a new  Budgeting  System  currently  under  develop- 
ment by  M.I.T.'s  Office  of  Administrative  Information 
Systems. 

\ 

Following  the  introduction,  Section  2 provides  a 
description  of  the  problem  context.  In  Section  3,  the 
various  activities  constituting  the  SDM  analysis  of 
the  new  Budgeting  System  are  discussed,  and  certain 
important  lessons  learned  there  are  reported.  The  SDM 
architecture  for  the  new  Budgeting  System  is  presented 
and  analyzed  in  Section  4. 

Research  implications  and  other  conclusions  are 
included  in  the  final  section.  The  reports  appendices 
contain  various  documentation  pertaining  to  the  study. 
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1.  INTRODUCTION. 

The  1970's  will  be  remembered  as  the  decade  in  which 
software  considerations  surpassed  hardware  considerations. 
Concerns  about  the  cost,  reliability,  and  ease  of  modifica- 
tion of  complex  computer-based  systems  are  now  largely 
focused  on  software,  not  hardware.  Furthermore,  it  is 
becominq  increasingly  clear  that  these  problems,  although 
detected  in  late  phases  of  the  system  development  process, 
in  fact  very  often  arise  because  of  basic  mistakes  made  dur- 
ing the  earlier,  less  structured  phases  (Horowitz  75,  Thayer 
75). 


The  change  in  priorities  from  hardware  to  software  has 


led  to  the  development  of  a collection  of  methods  and  ideas 


aimed  at  improving  the  software  design  and  development  pro 
cess.  While  there  are  certainly  some  differences  among 


these  approaches,  one  important  commonality  shared  by  them 


all  is  that  they  do  not  attempt  to  address  the  early  (prel 


iminary,  or  architectural)  phases  of  the  system  development 


process.  For  instance.  Dr.  G.  Myers,  primary  developer  of 


the  Composite  Design  Methodology  (one  of  the  methods  refer 


red  to  above),  points  out 


If  the  product  being  developed  is  a system,  rather 
than  a single  proqram,  there  is  another  design 
process  that  must  occur  between  the  external 
design  process  and  the  use  of  composite  design. 
This  process,  called  system  design,  is  the  decom- 
position of  the  system  into  a set  of  individual 


subsystems  or  individual  programs.  Although  some 
of  the  ideas  of  composite  design  are  appropriate 
here,  and  some  people  have  claimed  to  have  used 
composite  design  for  this  process,  composite 
desiqn  does  not  appear  to  be  directly  applicable 
to  system  design.  Therefore,  when  designing  a 
system,  as  opposed  to  an  individual  program,  the 
designer  must  first  partition  the  system  into  dis- 
tinct subsystems  or  programs.  Then  the  methodol- 
ogy of  composite  design  can  be  used  to  produce  the 
structure  of  these  individual  pieces. 

This  preliminary  partitioning  task  is  not  at  all  a tri- 
vial exercise.  In  fact,  one  of  the  reasons  it  has  received 
so  little  research  attention  to  date  is  simply  that  it  has 
been  viewed  as  analytically  intractable  - too  deep  and  com- 
plex to  be  successfully  structured  and  modelled. 

The  Systematic  Design  Methodology  (SDN)  is  a new 
approach  consisting  of  a set  of  concepts,  analysis  techni- 
ques, and  tools  to  assist  a software  architect  in  synthesiz- 
ing a desiqn  framework  early  in  the  design  process.  This 
framework  should 


1.  Be  based  on  a clearly  stated  set  of  requirement 
statements,  expressed  in  the  normal  language  of 
the  system's  users; 

2.  Convey  the  interdependencies,  both  tradeoffs  and 
reinforcements,  aironq  system  requirements  as 
viewed  by  the  designer; 

3.  Establish  sets  of  strongly  interdependent  require- 
ments, or  design  subpcobleirs,  that  ought  to  be 
considered  simultaneously  for  design  purposes; 

4.  Suggest  ways  in  which  solutions  to  the  alternative 
desiqn  subproblems  ought  to  be  coordinated  so  as 
to  obtain  an  enduring  global  design. 

The  SDN  is  currently  under  development  by  software  research- 
ers at  the  N.l.T.  Sloan  School. 


1.1  liJE  NEED  POR  SDJ1  EVALUATION 


The  Systematic  Design  Hethodology  research  to  date  has 


involved  both  methodology  development  and  application  stu 


dies.  The  applications  addressed  in  earlier  reports  include 


designs  for  a database  manager  (Andreu  77(a))  and  an  operat 


inq  system  (Holden  78).  In  both  cases,  however,  these  stu 


the  "real"  system  designers.  Por  this  reason,  they  pre 


sented  a somewhat  biased  result 


dual  performing  the  study  was  already  very  familiar  with  the 


methodology  itself,  its  goals,  and  operational  features 


Thus  there  was  little  or  no  designer  learning  time  involved 


(there  was,  however,  learning  time  as  regards  the  applica 


tion  being  addressed) 


Furthermore 


tors  did  both  report  that  using  SDH  seemed  to  provide  both 


direct  (an  effective  architecture)  and  ancillary  (a  better 
understanding  of  the  system  requirements)  benefits,  the 
credibility  level  of  their  assessments  must  be  judged  somcw 
hat  lover  than  would  be  those  of  a real  system  designer 


operating  with  a real  design  problem 


In  order  to  determine  how  well  SDH  would  perform  in  a 


real  design  context,  and  to  learn  how  a practicing  system 


architect  would  view  and  evaluate  it,  we  undertook  to  locate 


an  appropriate  scenario  within  which  to  carry  out  such  a 


study.  Fourteen  organizations  were  contacted  by  letter  and 


then  by  telephone,  and  five  indicated  they  (a)  currently  had 


an  appropriate  desiqn  problem  under  consideration,  and  (b) 
would  be  willing  to  spare  the  manpower  necessary  to  carry 
out  such  an  evaluation.  One  of  those  organizations  was 
H.I.T.'s  own  Business  Systems  Development  (DSD)  group.  It 
was  felt  that  DSD  was  the  best  choice  for  an  initial  outside 
application  study  for  three  different  reasons.  First,  com* 
munication  and  transportation  problems  would  clearly  be 
nonexistant  (all  the  other  organizations  were  located  in 
distant  cities).  Second,  following  an  initial  presentation 
of  the  concepts  and  objectives  of  the  SDH,  the  DSD  people 
concerned  seemed  genuinely  interested  and  willing  to  oxpend 
some  effort  in  a serious  evaluation  of  the  methodology. 
Finally,  the  system  deemed  most  appropriate  for  the  evalua- 
tion scenario  was  a fairly  conventional,  yet  reasonably  com- 
plex, data  processing  application  system.  As  the  earlier 
SDN  applications  had  been  concerned  with  systems  software  - 
a database  management  system  and  an  operating  system  - this 
study  promised  to  provide  new  insights  as  to  SDN  applicabil- 
ity to  such  application  systems  design. 

This  investigation,  then,  provides  the  first  signifi- 
cant unbiased  evaluat ion  ( 1)  of  the  usefulness  and  effective- 
ness of  the  methodology.  Also,  in  return  it  provides  the 
BSD  system  designers  with  an  SDN-derived  architecture  upon 
which  they  may  base  the  further  detailed  design  and  develop- 
ment of  their  target  system. 


(1)in  the  sense  that  the  assessment  data  comes  from  real 
system  designers,  not  the  SDN  researchers. 

- 4 - 


The  remainder  of  this  report  is  organized  as  follows. 

In  the  next  section,  background  information  on  the  target 
system,  a new  HIT  computer-base^  budgeting  system,  is  given. 
Section  3 contains  a discussion  of  the  process  of  applying 
the  SDH  to  the  Budget  System  architecture  design,  and 
includes  certain  observations  m»de  by  the  BSD  designers,  as 
well  as  lessons  learned  by  the  SDH  researcher,  in  the  course 
of  workinq  through  the  application.  Section  4 describes  the 
results  of  the  graph  decomposition  calculations,  and  pre- 
sents the  system  architecture  that  emerged  from  the  SDH  ana- 
lysis. Implications  of  the  suggested  architecture  are  also 
discussed.  Finally,  the  important  lessons  learned  from  this 
exercise  are  summarized  in  the  Conclusions,  Section  5.  The 
appendices  include  various  exhibits  pertaining  to  the  analy- 
sis and  decomposition  exercise,  including  original  and  final 
sets  of  requirement  statements,  and  the  interdependency 
assessments. 
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2.  APPLICATION  SYSTEM  BACKGROUND  - THE  MIT  BUDGETING 

SYSTEM. 

In  this  section  we  provide  brief  background  information 
on  the  specific  application  system  being  addressed  in  the 
study.  The  focus  is  a computer-based  system  to  support  the 
HIT  budgetinq  process.  This  system  will  be  referred  to  as 
the  Budqetinq  System.  A clear  distinction  must  be  made  bet- 
ween the  present  budgeting  system,  which  is  also  partially 
computer  based,  and  the  new  system  being  designed.  Both  the 
present  system,  and  considerations  for  the  new  one,  will  be 
discussed  below. 

Much  of  the  information  presented  below  was  gleaned 
from  two  sources:  a Sloan  School  of  Management  Master's 
Thesis  written  by  M.  Gutierrez  and  U.  Schirmer  which  pro- 
vides a detailed  description  of  the  present  MIT  budgeting 
process,  and  supporting  systems  (Gutierrez  and  Schirmer  77) ; 
and,  especially,  a report  written  primarily  by  the  chief 
designer  of  the  new  MIT  Budgeting  System,  H.  von  Letkemann 
(von  Letkemann  78). 

2.1  CURRENT  MIT  BUDGETING  ENVIRONMENT. 

In  this  report  the  terms  budget  and  budgeting  are  used 
in  a broad  context.  They  include  financial  planning  and 
financial  management,  and  therefore  overlap  with  other  ele- 
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merits,  qeneral  planning  at  one  end  of  the  spectrum  and  spe- 
cific accounting  or  reporting  at  the  other.  The  terms 


include,  but  are  not  limited  to,  the  existing  Institute 
budqet  system,  financial  target  setting  procedures,  fore- 
casting of  financial  requirements,  local  departmental  budg- 
eting systems,  and  generation  of  various  financial  reports. 

Budgeting  functions  at  HIT  take  many  forms.  In  this 
report  these  functions  are  divided  according  to  the  three 
levels  of  management  primarily  concerned  with  them.  The 
titles  listed  for  these  three  levels  are  examples  and  are 
not  meant  to  be  all  inclusive. 


1.  Top  Management  - concerned  with  Institute- wide 
planning  and  management.  This  group  includes  the 
President,  Chancellor,  Provost,  Treasurer,  certain 
Vice  Presidents  and  the  supporting  finance  and 
Budget  Offices. 

2.  Senior  Management  - concerned  with  planning  for, 
and  management  of,  specific  major  components  of 
the  Institute.  This  group  includes  the  Deans, 

Vice  Presidents,  Department  Heads,  and  the  Direc- 
tors of  Laboratories,  Centers,  and  programs. 

3.  Administrative  Management  - concerned  with  carry- 
ing out  the  plans  and  supporting  operations  of 
senior  management.  They  include  Administrative 
Officers,  and  certain  Administrative  Assistants. 

At  HIT  an  overwhelming  number  of  demands  for  funding  compete 
for  a finite  amount  of  resources.  The  Institute  has  a fis- 
cal 1979  operating  budqet  of  $336  million.  Of  this  amount 
approximately  $200  million  is  direct  expense  for  sponsored 
research,  $55  million  for  instruction  and  unsponsored 
research,  and  the  balance  for  support  services  and  auxiliary 
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activities.  There  are  about  130  budgeting  entities  consist- 
ing of  schools,  academic  departments,  interdepartmental 
laboratories  and  centers,  senior  officers,  support  depart- 
ments and  special  activities.  The  active  accounts  number 
about  10,000.  Resources  must  be  allocated  among  those  pro- 
grams in  a manner  consistent  with  the  academic  and  societal 
qoals  of  the  Institute. 

The  Institute  faces  substantial  fiscal  pressures  and 
constraints,  both  internal  and  external.  It  has  considera- 
ble fixed  expenses,  including  an  extensive  physical  plant 
and  a 60*  tenured  faculty.  Recent  shifts  in  enrolment  pat- 
terns have  strained  the  capacities  of  some  departments  and 
led  to  underutilization  of  others.  Externally,  the  impact 
of  inflation  has  been  substantial.  The  cost  of  materials 
and  services  has  gone  up  every  year,  arid  salaries  and  wages 
have  been  increased  in  an  attempt  to  keep  pace  with  the 
increased  cost  of  living.  Inflation  has  also  aggravated  a 
second  key  problem,  the  economic  slowdown  that  the  United 
States  has  experienced  for  the  last  several  years.  Although 
there  are  some  indications  of  recovery,  many  sources  of 
qifts  and  research  sponsoring  agencies,  including  government 
aqencies,  corporations,  foundations  and  individuals,  are 
still  boldinq  back  because  of  their  own  economic  problems. 
Additionally,  problems  such  as  the  ever  worsening  energy 
crisis,  and  additional  government  regulations  and  require- 
ments continue  to  burden  the  Institute's  limited  resources. 
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2.2  liLC  EXISTING  BUDGETING  SYSTEM. 

The  budqet  system  now  used  at  MIT  grew  as  a result  of 
responses  to  specific  requirements.  is  a need  was  recog- 
nized a new  component  of  procedure  came  into  existence.  The 
system  is  soundly  based  on  the  NIT  account  structure  and 
includes  some  analysis  functions.  These  characteristics 
make  it  a valuable  quide  for  any  new  system.  However,  it  is 
still  a loosely-connected  mixture  of  manual  procedures  and 
computer  operations.  The  system  has  not  been  developed  suf- 
ficiently to  take  advantage  of  the  available  data  already  in 
the  budqet  files  and  in  those  of  the  Accounts  Reporting  Sys- 
tem (ARS) . Other  important  data,  particularly  historical 
data,  is  not  even  in  these  files  and  must  be  developed  manu- 
ally from  various  sources.  The  functions  of  the  existing 
budqet  system  are  hampered  by  the  lack  of  an  integrated  base 
of  consistent  information.  This  has  kept,  it  from  being  the 
important  management  tool  it  could  be.  Some  of  the  limita- 
tions of  the  existing  procedures  are  discussed  from  the 
viewpoints  of  the  various  levels  of  management. 

2.2.1  Top  Management. 

The  reports  used  or  issued  by  Top  Management  at  MIT  are 
predominantly  manually  produced.  They  are  frequently  pre- 
pared in  response  to  changing  requirements.  Often  the  per- 
tinent data  does  not  exist  in  a computer-based  file,  or  if 
it  does  the  format  or  content  may  be  inconsistent  with  other 
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filos.  Even  periodic  reports,  such  as  the  Treasurer's 
Report,  the  operating  Budget,  the  calculation  of  research 
overhead,  the  HIT  Operating  Plan  (MITOP) , and  the  Dynamic 
Nodal (2)  are  produced  either  entirely  or  partially  by  hand. 

The  manual  preparation  of  a report  does  not  necessarily 
detract  from  its  value  or  content,  but  often  this  prepara- 
tion requires  extended  periods  of  scarce  managerial  time. 
Production  of  reports  either  entirely  or  substantially  by 
computer  vould  use  Institute  resources  more  efficiently. 

Cumbersome  manual  methods  of  handling  information  have 
a real  impact  on  what  information  is  used  and  what  is  done 
vith  it.  For  example,  the  Dynamic  Model  forecasts  Institute 
financial  scenarios  several  years  into  the  future  by  pro- 
lectinq  current  data  and  assumed  trends.  Because  of  the 
time  and  difficulty  involved  in  changing  the  assumptions  and 
runninq  additional  iterations,  only  a limited  number  of  com- 
binations are  reviewed.  If  the  model  could  be  changed  more 
easily,  more  combinations  of  variables,  and  their  relative 
impacts,  could  be  assessed  and  it  could  be  run  more  often. 
Then  manaqers  could  spend  their  time  more  effectively  in 
steerinq  controllable  elements  and  monitoring  important 
external  factors. 


(2) For  additional  detail  on  these  and  other  components  of 
the  current  budgeting  system,  refer  to  (Gutierrez  and 
Schirmer  77) . 


There  is  no  system  for  looking  ahead  several  years  by 
collecting,  evaluating  and  summarizing  the  planned  activi- 
ties and  expense  projections  of  the  senior  managers  of  the 
Institute  on  a regular  basis.  Even  when  setting  budget  tar- 
gets with  the  Chancellor  there  often  has  been  little  atten- 
tion paid  to  the  years  beyond  the  period  being  budgeted. 
Although  many  senior  managers  do  their  own  longer  range 
planning,  these  plans  and  projections  are  never  brought 
together  to  show  the  aggregate  of  the  estimates  and  their 
effect  on  where  MIT  will  be  three  to  five  years  hence. 

Fund  accounts  are  freguently  managed  iri  a less  than 
optimal  fashion.  For  instance,  an  unrestricted  gift  may  be 
received  and  then  designated  for  a specific  use  by  the 
Institute.  The  fund  is  then  accounted  for  according  to  that 
designation.  In  time  that  designation  may  begin  to  lose 
priority.  With  no  easily  accessible  record  to  show  that  it 
was  originally  an  unrestricted  gift,  there  is  no  way  to  be 
sure  that  the  gift  is  being  used  to  the  Institute's  best 
benefit . 


2.2.2  SSnj<?£  . 

As  with  top  management,  senior  management  must  rely 
heavily  on  the  current  and  previous  year's  figures  when 
developing  their  tuture  budget  plans.  Although  certain 
items  in  their  budgets  will  be  adjusted  by  the  Budget  Office 
to  reflect  salary  and  tuition  increases  and  other  changes. 
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it  is  sometimes  difficult  to  knot*  what  resources  will  be 
required  for  the  coming  year,  particularly  if  any  changes  in 
activities  are  planned.  The  President,  Chancellor  and  Pro- 
vost qive  qcneral  guidance,  but  they  depend  heavily  on  the 
ludqement  of  the  deans  regarding  new  subjects,  trends  in 
studont  demand,  and  research  undertaken.  The  absenco  of 
uniform  planning  and  budgeting  presentations  allows  for  a 
significant  amount  of  subjective  judgement  to  be  exercised 
in  the  establishment  of  the  budget  targets. 

In  the  cases  where  a request  of  the  senior  manager  for 
a budget  increase  is  accepted,  it  is  likely  that  the  request 
has  been  supported  by  a detailed  and  well  structured  projec- 
tion explaining  the  requirment.  Although  no  detailed  justi- 
fication nor  any  plan  beyond  the  next  fiscal  year  is  nor- 
mally required,  it  is  often  those  managers  who  document 
their  needs  and  provide  the  most  meaningful  presentations 
who  qet  the  most  consideration  for  additional  funding.  How- 
ever, the  current  budget  system  provides  almost  no  effective 
sdpport  to  those  managers  who  are  motivated  to  develop  such 
thorough  documentation. 

2.2.3  MiDiDistl-ltivfi  MamhlSE’SJVt . 

Administrative  management  is  the  group  closest  to  the 
day-to-day  financial  management  of  the  Institute.  As  a 
qroup,  it  has  the  greatest  need  for  current  and  detailed 
information  about  individual  accounts.  This  function  is 


supported  by  the  Institute  with  periodic  reports  such  as 
those  listed  below. 

The  Accounts  Reporting  System  (AKS)  provides  them  with: 
Detailed  Transaction  Report 
Bonthly  Statement 
Information  Summary 
Volume  Report 

Analysis  of  Expired  and/or  overrun  Accounts 
The  Budqet  Office  provides  them  with: 

Budget  Proposal  Forms 

Budget  Authorization  (green  sheet) 

Budget  versus  Actual  Analyses 
The  Payroll  department  produces: 

Salary  and  Wage  Expenses  by  .Individual 
Consolidated  Salary  Expense  Analysis 
The  ARS  reports  contain  essential  accounting  data,  including 
information  regarding  monthly  charges,  fiscal  year  and  cumu- 
lative figures,  and  authorized  budgets.  Commonly  mentioned 
shortcomings  of  ARS  reports  are  that  the  data  is  not  timely 
and  that  the  commitment  figures  are  not  always  meaningful. 
These  problems  are  inherent  in  the  design  of  the  current 
accounting  and  purchasing  systems. 

Budget  vs.  Actual  reports  produced  by  the  Budget  Office 
are  the  only  real  analyses  that  the  Institute  provides  the 
administrative  managers.  These  reports  compare  fiscal 
year-to-date  expenditures  with  Budget  Office  projections 


based  on  standard  expenditure  patterns.  While  the  projec- 
tions are  qonerally  sensible  and  realistic,  not  all  adminis- 
trators find  them  useful.  Under  the  current  system  however, 
these  reports  are  probably  the  best  that  could  be  produced 
on  an  Institute-wide  basis. 

In  many  instances,  individual  departments  have  devel- 
oped their  own  tailored  systems  to  monitor  actua 1-versus- 
budqoted  expenditures  or  provide  other  services  deemed 
important  by  that  department.  The  scope  and  sophistication 
of  these  "local"  systems  varies  widely.  However,  their 
existence  indicates  the  existence  of  a multitude  of  report- 
ing and  monitoring  needs  not  now  met  by  the  current  budget- 
inq  and  account inq  systems.  They  also  represent  a rich 
source  of  ideas  for  potential  featur.es  of  a new  budgeting 
system. 


2.3  GENERAL  REQUIREMENTS  F0£  A NfcW  BUDGETING  SYSTEM. 

In  this  section,  an  overview  of  various  user  require- 
ments for  a new  budqetinq  system  is  presented.  Those 
requirement  issues  are  derived  from  many  sources,  including 
interviews  with  management  personnel  across  the  Institute, 
other  interviews  and  questionnaire  survey  results  from  a 
study  of  the  planning  and  budgeting  practices  of  eleven 
other  colleqes  and  universities  (Hudock  77) , and  analysis  of 
the  current  HIT  Budgeting  system  operational  capabilities. 
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The  new  budget  system  will  build  on  many  strengths  of 


the  existing  Oudget  system  and  the  systems  developed  by  sev- 
eral of  the  administrators.  It  will  automate  many  of  the 
manual  procedures  and  extend  the  present  system's  capabili- 
ties by  increasing  the  data  available  to  both  the  Budget 
Office  and  the  departmental  users.  Capabilities  could  be 
expanded  by  sharing  the  data  bases  of  other  systems  and  by 
making  budget  data  available  to  users  in  other  areas.  Some 
additional  input  would  allow  improved  support  for  a broad 
range  of  financial  management  applications  and  additional 
reporting  capabilities.  These  features  are  discussed  in 
this  section  in  the  context  of  the  management  level  primar- 
ily involved. 

2.3.1  Preliminary  Technical  Issues . 

The  present  budgeting  system  is  batch-oriented  and 
heavily  involves  maqnetic  tapes  for  data  storage.  The  new 
system  would  provide  for  considerable  on-line  function,  as 
well  as  batch,  and  would  rely  much  more  on  disk  storage 
media.  Tapes  may  still  be  used  for  disk  backup,  and  possi- 
bly for  transferring  data  between  other  older  systems. 

The  new  system  will  be  developed  and  operated  on  one  of 
the  Institute's  l.B.H.  System/370  computers.  Storage  for 
the  proposed  database  will  require  on  the  order  of  one  full 
disk  pack  (3330-1  type).  The  system  will  be  able  to  inter- 
face with  different  terminal  types  so  as  not  to  constrain 
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the  system  users.  Any  terminal  which  normally  communicates 
with  the  370/168  should  be  acceptable.  A new  printer,  the 
IBM  3800,  is  desirable  for  the  new  system.  It  would  allow 
more  data  to  be  shown  on  a report,  could  produce  the  reports 
in  less  time,  and  would  print  them  on  8 1/2  by  1 1 inch 
paper.  A sample  copy  of  the  3800  output  is  included  in 
Appendix  A. 

The  new  system  will  be  designed  to  operate  in  conjunc- 
tion with  a database  management  system.  The  database  man- 
agement system  (DBMS)  will  support  storage  of  detailed 
information  and  allow  simple  access  and  updating  through 
batch  or  interactive  processing.  The  DBMS  will  support 
standard  and  non-standard  reports  and  inquiries,  and  func- 
tion independently  of  the  programs  and  systems  using  it.  It 
is  planned  that  the  database  management  system  will  interact 
with  many  systems,  increasing  its  usefulness  beyond  just  the 
budgetary  function. 

| 

2.3.2  Support  for  Top  Management. 

These  functions  are  categorized  in  three  areas:  spe- 
cial information  requirements,  standard  reports,  and  plan- 
ning. 

Special  information  support  for  top  management  basi- 
cally involves  supporting  the  need  for  "one-time*1  reports  or 
queries.  Although  it  is  not  feasible  to  anticipate  every 
request  for  such  information,  the  Budget  System  must  carry  a 
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wide  range  of  data  that  can  be  easily  accessed,  organized 
and  presented  as  required.  The  details  of  this  function  are 
somewhat  dependent  on  the  capabilities  of  the  database  man- 
agement system  used.  It  is  anticipated  that  the  data  would 
include  at  least  the  Chart  of  Accounts  and  detailed  monthly 
budget  and  actual  figures  for  each  object  code  for  each 
account.  Certain  data  for  past  fiscal  years  would  also  be 
included.  For  fund  accounts  there  would  also  be  historical 
information  that  could  facilitate  their  management.  For 
example,  fund  data  should  include  the  donor's  original 
designation  for  the  qift  and  its  related  income  as  well  as 
how  it  is  currently  being  used,  thereby  making  more  effec- 
tive fund  management  possible. 

The  new  system  would  continue  to  produce  most  of  the 
current  standard  reports,  including  (but  not  limited  to): 

The  Printed  Budget 

Certain  portions  of  the  Treasurer's  Report 

Indirect  Cost  Recovery  Percentage 

HITOP 

Dynamic  Model 

Periodic  Summary  of  Operations 
Modelinq  and  analysis  capabilities  must  be  provided  to 
explore  historical  data  and  to  project  observed  trends  and 
assumptions.  This  would  probably  reguire  a new  program  to 
replace  the  Dynamic  Model,  which  would  automatically  inter- 
relate the  various  assumptions.  This  would  facilitate  re- 


runninq  the  modol  so  as  to  check  out  assumptions  or  do  sen- 
sitivity analyses  on  individual  factors.  This  modeling  and 
analysis  system  could  be  developed  in-house  or  a commer- 
cially available  packaqe  might  be  used. 

If  HIT  is  to  take  full  advantage  of  the  new  system’s 
modelinq  and  forcastinq  capability  there  must  also  be  input 
concerning  the  plans  made  by  top  and  senior  management.  The 
budqet  system  would  provide  the  support  for  collecting, 
storing  and  providing  access  to  such  data.  The  most  impor- 
tant contribution  to  a forecasting  system  would  be  senior 
managers  submitting  their  plans  and  projected  expenses 
related  to  those  plans.  These  should  be  for  two  specific 
periods;  for  example,  a "short  range"  one  year  plan  and  a 
"long  range"  three  year  plan.  The  plans  should  be  in  a rea- 
sonably uniform  format  and  should  be  correlated  with  pro- 
posed budqet  targets  as  well  as  the  senior  managers*  area 
summaries  in  the  Report  of  the  President  and  Chancellor. 

The  Dudqet  and  Fiscal  Planning  Office  would  then  collect 
these  plans  and  projections  and  enter  them  into  a planning 
database  to  support  modelinq  and  forecasting. 

2.3.3  Support  for  Senior  Management . 

The  Budqet  System  would  provide  senior  manaqers  with 
standard  periodic  reports,  special  reports  and  access  to  the 
database  that  would  allow  them  to  make  their  own  inquiries 
and  analyses.  These  reports  would  contain  data  extracted 


from  the  Budqet  System  database  or  any  other  file  which  is 
normally  accessible. 
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Of  the  standard  periodic  reports  currently  produced  by 
the  Budqet  Office  only  the  Budget  Authorizations  issued 
prior  to  the  beginning  of  the  fiscal  year  would  remain  the 
same.  In  the  new  system  the  subsequent  budget  authoriza- 
tions and  chanqes  would  be  included  in  a Monthly  Analysis 
report.  The  Monthly  Analysis  would  also  replace  the  Budget 
vs.  Actual  Report.  This  report  would  be  a summary  of  the 
analyses  produced  for  administrative  management. 

Special  reports  for  senior  management  would  be  availa- 
ble on  request.  They  would  include  variations  of  the 
Monthly  Analysis  report  and  other  widely-used  reports.  It 
is  anticipated  that  they  would  be  requested  via  a terminal 
and  printed  either  at  the  terminal  or  on  a high  speed  prin- 
ter at  the  data  conter. 

Customized  reports  could  be  obtained  by  use  of  an 
easy-to-use  Report  Writer  language  to  access  the  database. 
Senior  managers  would  be  able  to  access  their  data,  perform 
various  kinds  of  calculations,  and  display  the  results  in  a 
variety  of  formats. 

The  Budqet  database  would  also  be  available  for  special 
inquiries  or  analyses  originated  by  senior  managers.  There 
would  be  support  for  batch  processing  as  well  as  a pre-pro- 
qrammed  "menu”  for  terminals  which  would  allow  easy  access 
to  the  database  for  the  most  common  types  of  inquiries. 
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More  complex  analyses  could  be  obtained  by  using  an  easily- 
learned  database  inquiry  language. 


! 


Protection  o f data  against  unauthorized  access  would 
most  probably  be  done  by  a system  of  passwords.  Within  a 
department  there  might  be  several  levels  of  security  depend- 
ing upon  the  sensitivity  of  the  data  and  the  "need  to  know.” 
Furthermore,  even  when  data  elements  would  be  accessible  to 
authorized  users,  most  of  them  would  be  on  a "read-only" 
basis.  To  maintain  database  integrity,  only  the  data 
"owner"  - such  as  ARS,  Payroll,  or  Budget  Office  - would  be 
allowed  to  add  or  chanqe  most  data. 

As  for  top  management,  there  is  a need  for  senior  man- 
agers to  submit  their  future  plans  and  projected  expenses. 
Not  only  will  this  aid  top  management  in  modeling  and  fore- 
casting, but  it  will  also  assist  senior  managers  in  present- 
ing a concise,  meaninqful  and  convincing  proposal  for  their 
financial  support. 

2. '3.  4 Support  for  Administr at ive  Management. 

Just  as  the  administrative  managers  have  the  most  inti- 
mate and  continuing  contact  with  budget  and  accounting  func- 
tions, they  would  experience  the  greatest  impact  from  the 
new  budget  system.  The  system  would  maXe  considerably  more 
data  available  and  would  provide  facilities  to  access  it. 

It  would  also  demand  more  of  them,  in  that  to  effectively 
use  the  system  they  must  provide,  and  revise  as  necessary. 


’ 
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month-by-month  projections  of  expenditures  and  income  for 
each  account  and  object  code.  The  system  would  make  this  as 
easy  as  possible  to  do.  Each  object  code  would  have  a stan- 
dard or  "default"  projections  formula  which  the  administra- 
tors could  either  accept  or  replace  with  their  own.  Projec- 
tion chanqes  within  an  object  code  would  be  made  directly  by 
the  Administrative  Officer  and  reviewed  by  the  Budget  Off- 
ice. Other  chanqes  to  the  budget  data  would  be  submitted  to 
the  Budqet  Office,  which  would  be  responsible,  as  it  is 
today,  for  review  prior  to  updating  the  database. 

Program  Budgeting  can  be  an  effective  tool  in  relating 
plans  or  goals  of  the  Institute  and  senior  management  to  the 
financial  resources  available.  It  is  a method  by  which 
budqets  are  established  along  program  or  activity  lines. 
Althouqh  some  administrative  managers  use  Program  Budgeting, 
others  budqet  and  monitor  solely  on  a line-item  basis.  The 
new  budqet  system  should  encourage  the  use  of  Program  Budg- 
eting. This  budqetary  method  would  be  far  more  useful  in 
monitorinq  expenditures  than  the  traditional  line-item 
budget.  In  addition,  program  budgeting  would  be  a signifi- 
cant aid  in  estimating  requirements  and  in  preparing  for  the 
target- setting  discussions  between  senior  managers  and  the 
Chancellor . 

The  Budqet  System  should  provide  manual  and  on-line 
options  for  the  preparation  and  submission  of  budget  propo- 
sals. Duplication  of  effort,  and  time  to  prepare  proposals. 


would  be  minimized  by  using  the  computet  to  do  the  calcula- 
tions and  make  projections  and  modifications  within  the 
budget  tarqet  amount. 

The  new  system  would  supply  all  the  periodic  informa- 
tion currently  contained  in  the  Budget  Authorizations  (after 
the  start  of  the  fiscal  year).  Monthly  Statements,  Informa- 
tion Summaries,  and  the  Budget  vs.  Actual  reports.  This 
would  be  done  with  a single  Monthly  Analysis  report,  which 
would  show  current  month,  fiscal  year  to  date,  budget  and 
other  data  in  a format  which  would  compare  actual  and  plan- 
ned account  activity. 

In  addition  to  replacing  these  Institute  reports,  the 
system  could  eliminate  the  requirement  for  some  of  the 
departmentally- produced  reports.  If  a department  still 
wished  to  have  its  own  special  formats,  they  could  do  so  by 
extracting  their  information  from  the  database  using  the 
Report  Writer  feature. 

The  Budqet  System  would  produce  optional  reports  on 
request.  These  would  include  standard  reports  for  non-stan- 
dard periods,  such  as  contract  year,  or  reports  which  would 
be  widely,  but  not  universally  used. 

The  system  would  support  the  additional  needs  of  admin- 
istrators for  inquiries  into  the  database  or  for  special 
analysos.  Access  to  the  data  would  be  read-only,  and,  sub- 
ject to  data  security  restriction,  would  use  the  same  facil- 
ities available  to  senior  management. 
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2.  3.  5 Support  lor  thg  Fiscal  planning  jnj  Budgeting 
Office. 

The  new  budqet  system  would  cause  some  significant 
chanqes  in  the  activities  of  the  Fiscal  Planninq  and  Budqet 
Office.  In  addition  to  most  of  its  current  responsibili- 
ties, there  would  be  the  establishment  and  maintenance  of  a 
database  for  the  lonq  ranqe  projections  of  the  senior  ma.n- 
aqement.  The  dollar  amounts  and  other  volume  fiqures  should 
provide  the  Budget  Office  with  the  base  for  a good  forecast- 
ing system. 

Processing  of  budqet  proposals  would  be  simplified  by 
the  use  of  computers  and  terminals,  greatly  reducing  the 
routine  manual  functions.  Proposals  could  be  accepted 
either  on  paper  or  via  department  terminals.  In  either 
case,  the  computer  would  edit  them  for  internal  consistency 
and  check  or  generate  necessary  totals.  The  computer  would 
determine  if  the  proposals  were  within  the  authorized  target 
amounts  and  also  check  for  open  accounts  without  proposals. 
Any  discrepancies  would  be  followed  up  by  the  Budget  Office. 

The  current  procedures  of  written  requests  and  appro- 
vals for  nonrecurring  equipment,  carryforward  amounts,  sab- 
batical leaves  and  other  special  expenses  would  remain 
unchanged.  The  approval  actions  would  enter  the  budget  sys- 
tem as  authorized  budget  changes. 

The  existing  Fund  Draft  procedure  would  remain  in 
effect,  except  the  input  log  sheet  would  be  replaced  by  a 
similar  record  entered  via  a terminal  or  batch  input  by  the 
managing  department  and  checked  by  the  Budget  Office. 
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The  budget  proposals  accepted  and  approved  by  the 
Budqet  Office  would  continue  to  be  adjusted  for  "dollar 
budgeting"  via  the  computer,  and  budget  Authorizations 
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("qreen  sheets")  would  be  printed  and  distributed  as  at  pre- 
sent. Once  the  fiscal  year  begins,  any  subsequent  adjust- 
ments would  appear  on  the  new  Monthly  Analysis  report  pro- 
duced from  the  budget  database.  A note  explaining  the 
change  would  also  be  shown. 

It  is  anticipated  that  the  Budget  database  would  have 
month-by-month  fiqures  for: 

Proposed  budget,  next  fiscal  year 
Authorized  budget,  this  fiscal  year 
Actual  expense,  this  fiscal  year 
Authorized  budqet,  last  fiscal  year 
Actual  expense,  last  fiscal  year 
Summarized  data  would  be  included  for  prior  years.  The 
database  would  also  carry,  or  be  able  to  access,  the  data 
from  the  Chart  of  Accounts,  account  makeup  and  non-standard 
support,  and  additional  data  as  required  for  fund  and 
research  accounts.  Non-standard  financial  agreements  bet- 
ween top  and  senior  management,  and  other  nonrecurring  tran- 
sactions, would  bo  catalogued  in  a special  Budget  Office 
file.  The  database  organization  must  allow  the  addition  of 
data  elements  that  are  not  currently  required  so  that  the 
database  can  grow  and  change  with  the  needs  of  the  Insti- 
tute. 
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3.  SDH  ANALYSIS  CF  THE  NE«  BUDGETING  SYSTEM 


In  this  section  we  describe  briefly  the  steps  that  were 
taken  in  conducting  the  SEN  analysis  of  the  MIT  Budgeting 
System,  and  the  methodological  lessons  learned.  The  key 
documents  developed  or  referenced  during  this  activity  are 
contained  in  appendices. 

As  mentioned  earlier,  the  SDN  researchers*  "interven- 
tion" in  the  Budgeting  System  design  activites  commenced 
with  a presentation  on  the  nature  and  purpose  of  the  metho- 
dology, attended  by  the  NIT  USD  staff.  Following  the  pre- 
sentation, it  was  agreed  by  the  researchers  and  the  DSD 
staff  that  the  Budget  System  was  probably  the  most  appropri- 
ate system  to  use  as  an  SEN  tost  scenario.  The  main  reason 
for  this  was  that  the  system's  development  was  at  the  right 
stage  - i.e. , most  user  reguiremonts  had  been  determined  and 
documented,  although  detailed  design  activity  had  not  yet 
commenced.  Also,  the  system  was  perceived  to  be  about  the 
right  size  and  scope  for  an  effective  SDN  study:  large 
enouqh  to  present  considerable  complexity  to  the  designers, 
but  not  so  large  as  to  overwhelm  the  SDN  researchers. 


3.1  BBOUU  EHENTS  PREP AR ATIC N 


The  first  step  in  the  study  was  to  prepare  a set  of 
SDN-oriented  requirement  statements  for  the  new  system. 
Pollowinq  initial  discussions  with  the  Budget  System  desig- 
ners, it  was  decided  that  the  designers  would  prepare  an 
initial  requirements  list,  which  would  later  be  modified,  if 
necessary.  This  initial  list  of  statements  was  prepared  by 
the  two  key  budget  System  designers,  H.  von  Letkemann  and  R. 
Shaw,  and  is  reproduced  in  entirety  in  Appendix  B,  These 
requirments  statements  were  developed  largely  out  of  exist- 
ing prose  documentation  of  the  needs  of  the  various  Budget 
System  user  groups,  similar  to  the  description  given  in  Sec- 
tion 2.3 

This  initial  set  of  requirement  statements  proved 
somewhat  inappropriate  for  SDN  use  for  various  reasons.  The 
most  important  difficulty  concerned  the  manner  in  which  many 
of  the  statements  had  been  constructed  by  the  designers.  As 
may  be  seen  in  Appendix  B,  many  statements  consisted  of  a 
very  general  "leader”  statement,  followed  by  a series  of 
sub-statements.  For  instance,  original  statement  19  was 

19.  Support  Special  reports  for  budget-related  activities. 

a)  Standard  reports  at  non-standard  times 

b)  Standard  reports  for  non-standard  periods 

i)  Contract  period 

ii)  Sponsor's  fiscal  year 

c)  Standard  data  in  non-standard  formats 
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d)  Report  writer  language  for  fully  customized 


reports.  This  language  must  be  easily  learned 
and  used. 

Also,  a number  of  the  statements  included  reference  to 
implementation  mechanisms,  something  to  be  avoided  at  this 
stage  in  system  design.  As  an  example,  original  statement 
18  read 

18.  On  Personnel  Action  Form  add  a box  to  indicate 
whether  person  hired  is  a replacement  or  an 
addition. 


* 

! 
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It  is  clear  that  as  stated,  this  reguirement  specifies  a 
procedural  technique  rather  than  a function  to  be  provided. 

Finally,  the  various  statements  exhibited  wide  varia- 
tions in  their  abstraction  level.  Statement  1,  for 
instance,  originally  read 

1,  Automate  as  many  manual  procedures  as  feasible 
to  save  time  and  effort. 


There  is  a rather  substantial  difference  in  abstraction 
level  between  statement  1 and  statement  18  (above).  In 
fact,  statement  1 was  later  removed,  as  it  was  felt  to  be  so 
all-encompassing  as  to  be  design- irrelevant. 
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Occasionally,  the  designees'  original  set  of  require- 
ment statements  included  requirements  for  issues  to  be  stu- 
died further,  as  opposed  to  the  functions  of  the  target  sys- 
tem. For  example,  oriqinal  statement  37  read 

37.  Determine  the  desirability  and  feasibility  of 
encumbering  salary  and  wage  budgeted  amounts. 

Statements  such  as  these  were  judged  to  be  "study  tasks," 
and  were  not  included  as  system  functional  requirements  in 
the  final  set  of  statements. 

A two-stage  approach  was  followed  for  re-writing  the 
set  of  functional  requirements  to  work  them  into  a form  more 
suitable  for  additional  SDM  analysis.  In  the  first  stage, 
the  SDH  researcher  re-drafted  all  the  statements  following 
the  qeneral  guidelines  discussed  in  {Fluff  78).  The  temp- 
lates concept  (see  Huff  78)  was  followed  in  framing  indivi- 
dual statements,  and  proved  quite  effective  in  helping  to 
meet  the  guidelines. 

In  the  second  stage,  the  designers  examined  the  re- 
drafted statements  to  make  additions,  corrections,  and  modi- 
fications. This  took  place  over  the  course  of  two  meetings, 
of  about  two  hours  each.  One  interesting  phenomenon  occur- 
red at  this  point.  in  many  instances,  the  designers  pos- 
sessed specific,  often  implementation-oriented,  information 
that  bore  upon  certain  requirements.  They  felt  that  it  was 
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important  that  such  information  be  inciuded  within  the 
requirement  statements  themselves.  However,  in  many  cases 
it  was  precisely  this  kind  _of  detailed,  implementation-or- 
iented information  that  the  requirements  had  been  redrafted 
to  avoid. 

One  of  the  underlying  principles  of  SDH  analysis  is 
that  requirement  statements  should  specify  functions  only, 
not  procedural  issues.  Including  procedural  information' 
("implementation  issues")  in  the  requirements  tends  to  unne- 
cessarily constrain  later  design  options  at  the  start,  per- 
haps resultinq  in  potentially  superior  alternatives  never 
beinq  considered.  However,  in  this  case  the  designers  were 
effectively  saying  that  various  good  procedural  ideas  had 
occurred  to  them,  and  they  would  "like  to  see  them  reflected 
in  the  requirement  statements."  Certain  other  factors 
played  a role  in  the  matter  as  well:  wanting  to  include 
reference  to  a "pet  idea"  of  particular  users;  wanting  to 
include  references  to  specific  techniques  or  devices  for 
which  it  was  felt  that  higher  authorities  might  require  some 
"sellinq. " 

An  effective  solution  to  this  problem  was  to  add  a Com- 
ment section  to  many  of  the  requirement  statements.  This 
feature  allowed  the  designers  to  include  additional  informa- 
tion, deemed  not  appropriate  or  relevant  for  the  basic 
requirement  statement,  but  which  they  desired  to  have  for- 
mally stated  alonq  with  the  basic  statements.  Examples  are 
contained  in  Appendix  C. 


The  two  meetings  mentioned  above  led  to  a reasonable 
set  of  functional  requirement  statements  for  use  in  further 
SDH  analysis.  Uowever,  this  was  by  no  means  the  final  ver- 
sion of  the  statements.  In  the  meetings  to  follow,  numerous 
additional  modifications  to  both  statement  form  and  content 
were  made.  Certain  new  statements  were  added  in  light  of 
improved  understanding  that  occurred  as  a result  of  these 
discussions.  Similarly,  some  other  statements  were  deleted 
or  merged  together,  and  minor  or  major  wording  alterations 
were  made  to  many.  The  final  version  of  the  Budgeting  Sys- 
tem Functional  Requirement  Statements  is  given  in  Appen- 
dix C. 

Another  mechanism  found  useful  in  the  development  of 
the  requirement  statements  involved  the  use  of  the  Waterloo 
Script  text  formatting  system  ("WSCF.IPT”)  which  runs  on 
H.I.T. *s  I Bfl  System/370  computer.  This  powerful  formatter 
allows  the  user  to  write  command  macros.  One  such  macro  was 
used  to  provide  automatic  numbering  control  on  the  require- 
ment statements.  Through  this  means,  statements  could  be 
added,  deleted,  or  their  sequence  altered,  without  requiring 
extensive  and  time-consuming  statement  renumbering. 

3.2  INTERDFPENDENCY  ANALYSIS. 

Once  the  requirement  statements  had  been  expressed  in  a 
form  appropriate  to  SDH,  work  began  on  determining  the  exis- 
tence and  strength  of  the  various  requirement  inter dependen- 


cics.  This  work  was  carried  out  in  a serios  of  six  joint 
meetings,  each  lasting  about  two  hours. 

A simple  form  was  designed  for  carrying  out  the  inter- 
dependency analysis,  a copy  of  which  is  includod  here  in 
Appendix  0.  The  approach  followed  was  straightforward. 
Beginninq  with  requirement  pair  (1,2),  each  individual  con- 
sidered whether  or  not  a significant  implementation  interde- 
pendency existed  between  the  two  requirements.  This  assess- 
ment was  carried  out  by  considering  "conceptual  models"  of 
the  implementation  of  each  requirement  in  the  pair,  then 
determining  in  the  context  of  these  models  whether  or  not 
there  would  arise  any  concordant  or  discordant  interaction 
between  them.  These  notions  of  mental  implementation 
modols,  and  concordant  and  discordant  interdependencies  have 
been  described  in  depth  in  (Andreu  77(b)).  The  basic  idea 
is  as  follows: 

1.  First,  one  thinks  about  how  the  first  requirement 
would  most  likely  bo  implemented.  This  generally 
requires  thinking  through  some  detailed  design, 
procedural-type  issues. 

2.  With  that  "mental  model"  in  mind,  tao  same  thing 
is  done  as  regards  the  second  requirement. 

J.  Then  the  two  mental  models  of  implementation  are 
jointly  compared  to  determine  whether 
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a)  one  scheme  makes  it  easier  to  implement  the 
other  (condordance)  ; 

b)  one  scheme  makes  it  mgre  difficult  to  implement 
the  other  (discordance) ; 

c)  there  is  no  appreciable  overlap,  or  interac- 
tion, in  the  above  sense,  between  the  two. 

The  result  of  this  comparison  suggests  the  existence 

or  non-existence  of  an  interdependency  between  the 

requirements  under  consideration. 


4,  Finally,  the  strength  of  each  interdependency  was 
assessed.  Strength  ratings  were  chosen  from  a set 
of  three  alternatives: 

S - strong 
A - average 
H - weak. 

While  interpolation  and  extrapolation  of  these 
categories  are  possible,  these  three  alternatives 
were  found  to  be  satisfactory  for  this  project. 

The  interdependency  strength  assessment  was  made 
judqmentally , based  on  the  perceived  amount  of 
••overlap,"  or  interaction,  between  the  mental 
models  being  contrasted. 


In  practice,  the  different  individuals 
assessment  activity  nearly  always  agreed  on 
strenqth  value  for  a given  interdependency, 
then,  these  assessments  should  be  judged  to 
consistent  between  different  designers. 


involved  in  the 
a common 
Intuitively, 
be  reasonably 
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Interdependency  analysis  proved  to  be  somewhat  more 
difficult  for  the  desiqners  than  expected.  The  main  reason 
for  this  seemed  to  be  the  difficulty  in  constantly  keeping 
in  mind  precisely  what  interdependency  assessment  was  sup- 
posed to  be.  Specifically,  there  was  a noted  tendency  for 
the  focus  to  shift  from  issues  about  how  two  particular 
requirements  might  be  related  at  t^e  implementation  level . 
to  whether  or  not  they  were  logically  related.  An  example 
of  this  phenomenon  should  make  it  clearer.  Requirements  56 
and  57  are,  respectively 

56.  Budqet  proposals  can  be  prepared  manually. 

57.  Budqet  proposals  can  be  prepared  on-line. 


Now,  on  first  qlance  it  might  appear  that  since  both 
requirements  pertain  to  budget  proposal  preparation,  they 
must  have  an  interdependency,  probably  a strong  one.  This 
would  be  an  instance  of  what  was  termed  "logical  relation- 
ship," above.  In  practice,  this  kind  of  logical  relation- 
ship is  easier  to  identify  than  is  the  implementation- level 
interdependency,  consequently  they  often  "jumped  out"  at  the 
desiqners  during  the  interdependency  analysis  activity, 
tending  to  further  obscure  the  search  for  true  implementa- 
tion interdependencies.  The  only  solution  to  this  problem 
was  for  the  SON  researcher  to  continually  ask  the  designers 
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whether  a qiven  inter dependency  they  had  determined  to  exist 
was  in  fact  a result  of  implementation  overlap,  or  something 
else.  If  the  answer  was  "something  else"  (e.g.,  in  the 
above  example,  the  source  of  the  initial  interdependency 
assessment  was  "both  requirements  concern  budget  proposal 
preparation")  then  we  had  to  think  more  carefully  about  the 
requirements  and  our  mental  models  of  their  implementation 
within  the  target  system.  In  the  above  example,  this  re- 
thinking did  in  fact  lead  to  an  implomentat ion  interdepen- 
dency, ludqed  to  be  weak  in  importance.  The  underlying 
arqument  concerned  a key  implementation  model,  the  concept 
of  a suspense  or  holdinq  file  for  budget  proposals,  that  was 
seen  as  leading  to  a concordant  interdependency  between  the 
two  requirements. 

3.3  SOME  LESSONS  iEAFNEC. 

The  interdependency  analysis  activity,  as  mentioned 
above,  consumed  approximately  eleven  hours  of  meeting  time. 
This  is  a not  inconsiderable  load.  However,  in  this  case  at 
least,  the  meetings  were  judged  to  be  profitable  exercises 
in  a sense  independent  of  any  potential  benefits  that  may 
emerqe  from  the  SOS-produced  architecture  per  se.  Specifi- 
cally, some  important  issues  regarding  the  Dudget  System 
were  raised,  discussed,  and  cleared  up  or  at  least  better 
understood  as  a result  of  the  careful,  repeated  study  being 
qiven  to  each  requirement.  This  effect,  is  raised  and  dis- 


cussed,  and  modelled  as  an  important  SDH  benefit  in 


(Huff  7$b) 


The  most  general  side  benefit  gained  from  the  SDH  ana 


lysis  exercise  concerned  a heightened  awareness  and  under 


standing  of  all  the  "pieces"  of  the  new  Budget  System,  and 


now  they  fit  together.  The  designers  indicated  that  working 


through  the  SDH  activities,  especially  the  interdependency 
analysis  step,  served  both  an  integrating  and  differcntiat 
inq  function.  Developing  implementation-free  requirement 


statements  tended  to  force  them  to  "stand  back,"  to  abstract 


from  many  of  the  specific  implementation-oriented  details 


with  which  they  were  generally  concerned,  thus  helping  them 


to  develop  a better  grasp  of  the  "big  picture 


of  this  concerns  original  requirement 


5c)  Provide  checks  to  ensure  that  each  person 


is  not  budgeted  more  than  100X  E.F.T 


Discussion  of  this  requirement  led  to  the  broader  recogni- 
tion that  what  was  really  desired  was  a general  set  of  edit 
inq  and  checking  capabilities,  not  limited  to  this  one  par- 
ticular aspect.  Hence  the  more  qeneral  requirement. 


58.  Budgeted  proposals  will  be  automatically 


checked  and  edited  to  the  extent  possible 


emorqed.  Nonetheless,  the  problem  with  EFT  (effective 
full-time)  budgeting  of  certain  staff  occasionally  exceeding 
100%  was  felt  to  bo  an  important  instance  of  the  general 
requirement,  so  was  included  in  the  final  set  of  require- 
ments as  a comment. 

Another  class  of  lessons  learned  concerns  new  ideas 
that  occurred  to  the  designers  as  a result  of  working 
throuqh  the  SDM  analysis.  A good  example  of  this  was 
related  by  the  chief  designer  during  one  of  the  meetings. 

It  concerned  his  observation  of  the  parallels  between  the 
research  proposal  tracking  and  budget  proposal  tracking 
tasks.  In  the  past  these  activities  were  viewed  and  treated 
separately.  However,  through  having  to  think  carefully 
about  the  relationships  among  the  requirements  in  the  course 
of  the  interdependency  analysis,  he  had  come  to  recognise 
many  procedural  commonalities  between  the  two  general  activ- 
ities. This,  he  pointed  out,  suggested  new,  potentially 
better  ways  of  performing  the  former  task  based  on  ideas 
that  had  been  developed  for  performing  the  latter.  At  the 
present  time  the  procedures  tor  performing  the  two  tasks  are 
quite  different.  Essentially,  the  need  to  develop  a mental 
implementation  model  for  the  research  pro[osal  tracking 
requirement  led  the  designer  to  consider  a similar,  better 
understood  model  for  the  budget  proposal  tracking  require- 
ment, which  in  turn  led  to  the  idea  of  implementing  both 
requirements  in  a common  fashion.  This  may  be  thought  of  as 


37 


a kind  of  inverted  interdependency  analysis:  rather  than 
derivinq  the  interdependency  from  the  conceptual  implementa- 
tion models,  one  implemented  model  was  derived  from  the  sec- 
ond model  and  the  perceived  potential  interdependency.  The 
normal  and  inverted  patterns  of  interdependency  analysis  are 
illustrated  in  Figure  3.  1 (a)  and  (b)  . 

A third  category  of  benefit  reported  by  the  designers 
vas  that  working  with  the  SDH  concepts  gave  them  some  useful 
new  ways  of  thinking  about  system  design  irj  general  (not 
restricted  to  this  specific  system).  The  most  frequently 
cited  case  concerned  the  central  SDH  concept  of  separating 
functional  issues  in  the  requirement  statements,  and  imple- 
mentation issues  in  the  interdependency  assessments.  The 
designers  reported  that  they  found  this  a most  useful  way  of 
organizing  their  thoughts  in  addressing  system  design  prob- 
lems, and  in  fact  found  themselves  using  the  concepts  when 
discussing  design  issues  with  other  parties.  They  reported 
conversations  with  the  Business  Systems  Development  manager 
(their  boss)  in  which  the  SDH  conceptual  framework  was  used 
to  help  clarify  certain  design  issues  being  discussed. 

Another  category  of  "lesson"  that  ought  to  be  mentioned 
concerns  the  importance  of  what  we  will  call  "political" 
issues  in  the  system  preliminary  design  process.  As  with 
practically  any  activity  that  results  in  impacts  on  the 
working  needs  and  relationships  of  the  members  of  the  organ- 
ization in  which  it  operates,  system  design  activities  are 
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Requirement  1 

♦ 

Implementation 
Model  1 


leads  to 


Requirement  2 


Implementation 
Model  2 


Figure  3.1(a) 

Normal  pattern  for  Interdependency  Assessment 


Requirement  1 


Figure  3.1(b) 

Inverted  pattern  for  Interdependency  Assessment 
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subject  to  more  than  strictly  "technical"  concerns.  In  the 
case  of  system  preliminary  design,  these  concerns  fall  into 
two  main  groups:  (a)  impact  of  system  design  activities  on 
the  needs  of  eventual  users  of  the  target  system,  and 
(b)  impact  on  the  needs  of  the  designers  and  developers  of 
the  system.  The  SDH  exercise  brought  to  light  cases  of. both 
types.  This  was  found  useful  by  the  designers,  although  not 
because  they  believed  that  these  hinds  of  issues  ought  not 
enter  the  design  process  at  all.  In  most  cases  the  desig- 
ners were  not  really  in  a position  to  make  such  a judgment. 
Bather,  it  was  seen  to  be  beneficial  simply  to  recognise  the 
nature  of  the  reasoning  underlying  such  considerations. 
Design  decisions  involving  "polit ically -based"  requirements, 
for  instance,  might  be  handled  in  a manner  different  than 
that  for  other  requirements. 

An  example  of  this  issue  concerns  the  need  for  the 
Budqet  System  to  interface  and  share  data  with  certain  other 
existing  administrative  data  processing  systems.  The  desig- 
ners, in  assessing  interdependencies  among  requirements  that 
involved  this  need  for  data  sharing,  found  themselves  limit- 
ing their  thinking  to  certain  implementation  approaches  and 
ruling  out  other,  potentially  good  approaches  that  were  seen 
as  "politically  infeasible"  for  some  reason.  In  another 
instance,  the  designers  suggested  that  certain  items  ought 
to  be  included  (generally  as  comments)  in  the  SDM  require- 
ment statements  on  the  grounds  that  some  other  individual  or 
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organizational  entity  "would  want  to  see  it  there."  There 
were  also  some  instances  of  comment  items  stemming  from  the 
designers*  desires  to  give  expression  to  particular  techni- 
ques or  approaches  they  felt  to  te  especially  important.  As 
a hypothetical  example,  a designer  might  bo  convinced  (per- 
haps quite  correctly)  that  a particular  device  would  be 
necessary  to  properly  meet  one  or  more  user  requirements. 
Therefore,  even  though  the  choice  of  device  could  bo  argued 
to  be  an  "implementation  approach"  to  meeting  the  require- 
ments, the  designer  miqht  choose  to  include  a reference  to 
the  particular  device  as  a comment  on  the  requirement  state- 
ment, so  as  to  help  develop  a mental  association  between  the 
device  and  the  requirement  in  the  minds  of  the  users  reading 
the  requirement  statements  later  on, 

Andreu  expressed  concern  over  the  time  required  to  exe- 
cute the  SDK  interdependency  analysis  on  requirements  sets 
of  nontrivial  size  (Andreu  78) . He  countered  this  concern, 
however,  with  the  observation  that  the  interdependency 
matrix  is  quite  sparse,  hence  the  problem  is  not  as  serious 
as  it  might  at  first  appear.  This  turned  out  to  be  accurate 
in  the  present  case  as  well.  For  the  Budgeting  System,  77 
requirements  were  determined,  and  289  interdependency 
assessments  made  over  a course  of  about  12  hours.  This 
represents  approximately  four  interdependencies  per  require- 
ment, and  approximately  2.4  minutes  per  assessment.  Note 
however,  that  the  total  potential  number  of  interdependen- 
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cies  is  77x76/2  = 2926.  Using  the  total  figure,  the  assess- 
ment rate  turned  out  to  be  15  seconds  per  interdependency 
assessment.  The  fact  that  about  90%  of  the  requirement 
pairs  are  of  the  "easy"  assessment  type,  and  hence  require 
very  little  study  time,  makes  the  entire  interdependency 
assessment  activity  feasible. 

In  carrying  out  his  D2SS  application  study,  Andreu  per- 
formed all  the  interdependency  assessment  himself  - i.e.,  he 
played  the  role  of  a single  DBHS  designer.  He  later  pointed 
out  (Andreu  78,  page  232)  the  fact  that  he  felt  a group 
approach  to  the  assessment  activity  might  work  out  well,  in 
that  individual  designers  need  reinforcement  of  their  think- 
inq  process  from  other  designers  to  insure  them  that  they 
are  not  "way  off  base."  This  in  fact  did  seem  to  be  the 
case  with  the  Budgeting  System  assessment  exercise.  Having 
three  people  thinking  about  the  interdependencies  definitely 
resulted  in  a clearer  and  more  consistent  set  of  interdepen- 
dency, and  in  the  propagation  of  ideas,  modification  and 
improvements  to  the  requirements,  etc.  that  would  not  all 
have  been  generated  by  any  single  individual.  An  effective 
balance  - between  target  system-relevant  knowledge  possessed 
by  the  designers,  and  SDK-oriented  concepts  better  under- 
stood by  the  SDK  researcher  - was  in  evidence.  On  numerous 
occasions,  the  SDK  researcher  suggested  possible  interdepen- 
dencies that  were  discounted  by  the  designers  as  a result  of 
their  better  grasp  of  the  needs  of  the  target  system.  In 
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contrast,  the  SDN  researcher  was  effective  in  maintaining 
the  correct  focus  during  the  requirement  statement  dovelop- 
• meat  and  interdependency  assessment  activities,  as  discussed 
earlier.  The  materialization  of  this  symbiosis  suggests 
that  a qroup  approach  to  interdependency  assessment  is  prob- 
ably the  most  fruitful  one. 

3 . 4 SUHiURY . 

This  exercise  has  indicated  clearly  that  there  are 
immediate  design  benefits  to  be  had  from  the  SDN  require- 
ments preparation  and  interdependency  analysis  activities. 
The  common  source  of  these  benefits  lies  partially  in  the 
simple  fact  of  having  to  think  carefully,  and  repeatedly,  in 
a structured  way,  about  what  each  requirement  really  means, 
about  how  each  might  be  implemented,  and  about  how  alterna- 
tive implementation  schemes  interact.  In  the  next  section 
we  analyze  the  architecture  for  the  new  Budgeting  System 
that  emerges  from  this  analysis. 


4.  AM  ARCHITECTURE  FCE  HIT'S  NEW  BUDGETING  SYSTEM. 

Once  the  interdependency  analysis  has  been  completed, 
the  interdependency  statements  can  be  entered  into  the  com- 
puter for  use  in  the  decomposition  analysis.  The  Budgeting 
System  interdependency  statements  are  of  the  form: 

nodel  node2  weight  description 

The  weiqht  values  are  entered  as  'W',  'A',  or  'S',  as  dis- 
cussed earlier.  The  "description"  is  a brief  text  commen- 
tary used  to  document  the  rationale  underlying  the  desig- 
ners* assessment  of  the  existence  of  that  particular 
interdependency.  A complete  listing  of  the  Budgeting  System 
interdependencies  is  given  in  Appendix  E. 

It  should  be  noted  that  the  capability  of  entering, 
storinq , and  retrieving  interdependency  descriptive  informa- 
tion was  judged  by  Andreu  to  be  an  important  feature  not 
present  in  his  initial  version  of  the  S DM  analysis  package. 
While  the  techniques  that  have  been  developed  for  this  pur- 
pose in  the  current  effort  have  been  found  useful,  there  are 
some  further  improvements  that  could  be  made,  and  are  dis- 


cussed in  the  final  section 


4 . 1 DECOMPOSITION  ANALYSIS  RESULTS . 


The  Budqotinq  System  interdependencies  define  its 
requirements  qraph.  The  interdependencies  data  file  (Appen- 
dix E)  was  converted,  usinq  the  analysis  package,  to  another 
data  file  (containing  no  text  information)  that,  could  then 
be  used  as  input  to  the  MASTER  decomposition  routines.  These 
routines  were  described  and  documented  in  (Huff  79a). 

The  facilities  of  the  analysis  package  were  then  used 
to  develop  decompositions  of  the  requirements  graph,  to 
evaluate  them  usinq  the  objective  function  M,  to  modify  and 
manipulate  the  decompositions  in  various  ways,  and  to  save 
and  print  out  the  results  so  obtained. 

Each  of  the  five  decomposition  techniques  (four  clus- 
tering techniques,  and  the  interchange  algorithm)  were 
applied  to  the  Budgeting  System  requirements  graph.  The 
outcomes  are  shown  in  Table  4.1.  Of  the  four  clustering 
methods,  HIEft 3 produced  the  best  overall  decomposition,  with 
an  objective  function  value  of  M = 0.67.  The  objective 
function  values  for  HILF1,  HIER2,  and  HIEF4(3)  were,  respec- 
tively, 0.05,  0.27,  and  0.27. 

The  interchange  algorithm  was  also  applied  to  the 
requirements  qraph,  and  produced  a decomposition  with 
M ■ 0.85.  This  decomposition,  then,  was  judged  to  be  the 
best  in  terms  of  identifying  high-strength,  low-coupling 
subgraphs  (as  measured  by  M)  . This  best  decomposition  of 


(3)These  algorithms  are  discussed  in  detail  in  (Huff  79a)  . 
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Objective  Function  Value 
Xfil  Jigst  located  Decomposition 


HI  LR  1 0.05 

HIER2  0.27 

HIER3  0.67 

HIER4  0.27 

INTERCHANGE  0.85 

Table  4.J 


Comparison  of  results  of  five  decomposition 
algorithms  on  the  Budgeting  System  requirements  graph 


the  requirements  graph  produced  by  the  interchange  method  is 
illustrated  in  Piqure  4. 1.  Appendix  F contains  a listing  of 
the  abbreviated  budgeting  System  requirements  (no  Comment 
sections  included  there,  for  brevity)  organized  according  to 
subqraph.  Finally,  Appendix  G contains  a listing  of  the 
inter-requirement  links  between  each  identified  pair  of  sub- 
graphs. 

The  task  that  remains,  then,  is  to  study  the  decomposi- 
tion - both  the  requirements  subsets,  and  the  sets  of  inter- 
dependencies between  requirement  subsets  - so  as  to  formu- 
late an  interpretation  or  the  graph  decomposition  as  a 
system  architecture.  At  the  same  time  we  seek  to  identify 
anomalies,  courter intuitive  results,  etc.,  that  might  indi- 
cate earlier  errors  in  assessments,  requirements  formula- 
tion, etc.  Alternatively,  anomalous  results  might  turn  out, 
on  closer  inspection,  to  be  correct  after  all,  but  simply 
unforseen.  Such  issues  will  be  examined  in  greater  detail 
in  the  next  section. 

4.2  ANALYSIS  OF  J3JtjSI(iN  SUBPRODLEMS . 

A total  of  eleven  design  subproblems  were  identified  in 
the  best  decomposition  or  the  requirements  graph.  Three  of 
these  subproblems  are  "middle-sized,"  containing  15,  19,  and 
13  requirements;  the  remainder  art-  somewhat  smaller,  rang- 
ing in  size  from  two  to  seven  requirements  each. 


Subgraph 


Requirements 


1 7,28,38,56,57-62,05,66,68,71,76 

2 18-26,29, 31-34, 36, 39-42 

3 16,43-52,64,74 

4 15,77 

5 9,10,13 

6 53-55,67,69,  70 

7 11,12,14 

8 5,6,27,35 

9 8,63,75 

10  1-4,17,30,37 

11  72,73 


Figure  4._1 


Best  located  decomposition  produced  by  the  intercuange 
method  on  the  Budgeting  System  requirements  graph. 
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Fiqure  4.2  shows  the  relationships  between  the  eleven 
design  subproblems  and  the  21  inter-subproblem  linkages. 
This  fiqure  will  be  expanded  with  additional  descriptive 
information  following  our  discussion  of  the  individual  sub- 
problems and  linkages  in  this  and  the  next  section. 


Subprob lem  1 r Preparation  o£  Budget  Proposals. 

This  subproblem  centers  on  the  preparation  of  budget 
proposals.  Cne  of  the  intended  features  of  the  new  Budget- 
ing System  is  a much  more  streamlined,  easier-to-use  set  of 
proposal  preparation  facilities,  including  on-line  prepara- 
tion, automatic  checking  and  cross-checking  of  entered  data 
for  consistency  and  reasonableness  of  values,  on-line  exami- 
nation by  the  Budqet  Office,  and  on- lino  modification  by  the 
budqet  preparers  (administrative  officers,  department  heads, 
etc.).  Host  of  the  requirements  in  this  subproblem  hinge 
directly  on  these  related  activities. 

Requirements  7,  2B,  38,  62,  and  68  all  arc  related  to 
the  maintenance  of  various  kinds  of  data  directly  rulevant. 
to  proposal  preparation.  The  fact  that  these  data  sources 
are  identified  together  is  useful  for  later  detailed  design 
of  tho  Uudqeting  System  database  - e.g.,  when  deciding  on 
seqment  structure,  record  layouts,  etc.,  it  is  most  useful 
to  have  a clear  idea  of  what  data  is  most  likely  to  be  used 
jointly  or  in  closely  related  activities. 


49 


Subproblem 


Relationships  among 


Requirements  56  and  57  pertain  to  the  proposal  prepara- 


tion process  itself.  Requirements  58,  59,  60,  and  61  all 
pertain  to  the  issues  surrounding  the  checking,  editing,  and 
revision  of  budget  proposals  or  changes  to  pending  propo- 
sals. Requirement  71,  regarding  fund  draft  checking,  is 
closely  tied  to  various  other  requirements  within  this  sub- 
problem, including  those  involved  with  special  financial 
arrangements  (7,68),  and  those  requirements  with  similar 
processing  steps  (59,60,61,62). 

There  are  two  seeming  anomalies,  in  the  presence  of 
requirements  65,  66,  and  76  in  this  subprobloin.  A deeper 
examination,  however,  reinforces  the  correctness  of  this 
assignment.  Requirements  65  and  66  involve  handling  of 
research  proposals  by  the  Budgeting  System.  Researcn  propo- 
sals may  not  appear  at  first  glance  to  have  much  in  common 
with  budget  proposals.  However,  as  discussed  in  Section  3.3 
earlier,  one  of  the  useful  discoveries  made  by  the  chief 
designer  in  the  course  of  the  SDH  interdependency  analysis 
was  the  existence  of  strong  potential  implementation  paral- 
lels between  the  handling  of  research  and  budget  proposal 
preparation.  (4)  These  parallels  manifest  themselves  in 
interdependencies  that  eventually  result  in  the  research 
proposal  preparation  requirements  being  grouped  together, 
for  design  consideration  purposes,  with  the  budget  proposal 
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( 4) spec  if ica 1 ly , the  use  of  a common  suspense  tile  approach 
pending  final  acceptance  of  the  proposals. 


preparation  requirements. 

The  existence  of  requirement  76  in  Subproblem  1 simi- 
larly makes  good  sense  upon  closer  examination.  The  Insti- 
tute's overhead  recovery  rate  is,  in  fact,  a key  item  of 
information  in  budqet  proposal  preparation.  The  rate  is 
adjusted  as  a function  of  the  Institute's  financial  situa- 
tion each  year.  The  intention  in  the  new  Budgeting  System 
is  to  estimate  the  rate  for  the  coming  fiscal  year  on  the 
basis  of  information  available  in  the  budget  proposals 
(hence  requirement  7b)  and  make  this  estimate  available  to 
the  budqet  officers  for  their  proposal  preparation  activi- 
ties. Thus  the  manner  in  which  recovery  rate  calculations 
are  made  is  closely  tied  in  with  proposal  preparation,  so 
should  be  considered  toyether  for  design  purposes. 

Subproblem  2 - Operations  henortino. 

The  second  subproblem  is  the  largest  in  terms  of  the 
number  of  requirements  included:  19  requirements.  its  cen- 
tral focus  miqht  be  termed  "operations  reporting."  Basi- 
cally, this  subproblcm  addresses  monitoring  of  actual  income 
and  expense  information  against  the  operating  budget  - i.e., 
the  control  side  of  the  budgetary  process.  Since  this  is 
perhaps  the  largest  and  most  important  function  to  be  pro- 
vided by  the  new  Budgeting  System,  it  is  most  appropriate 
that  it  should  also  turn  out  to  be  the  focus  of  the  largest 
design  subproblem. 
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Certain  of  the  requirements  in  this  subgroup  directly 
address  the  operational  analysis  and  reporting  capabilities 
• of  the  new  system,  including  requirements  18,  19,  29,  31, 

33,  and  39.  Many  of  the  remaining  requirements  ended  up  in 
this  qroup  because  of  strong  data  interrelationships  between 
them  and  the  ones  cited  above.  This  includes  requirements 
20  throuqh  26.  These  requirements  specify  that  certain 
databases  will  be  maintained  by  the  Budgeting  System,  data- 
bases intimately  linked  to  the  provision  of  the  monitoring 
and  reporting  functions  to  be  provided. 

It  is  interesting  to  note  that  these  requirements  end 
up  together  in  the  requirements  decomposition  because  of 
their  data-oriented  interrelationships,  as  opposed  to  their 
processing  interrelationships.  One  of  the  recent  "discover- 
ies" in  software  engineering  research  concerns  the  fre- 
quently underestimated  importance  of  the  role  of  data  struc- 
tures and  data  handlinq  in  system  design.  Earlier  work 
usually  assumed  program  control  flow  to  be  the  pre-eminent 
concern,  data  organization  to  be  of  secondary  importance; 
more  recent  work  has  tended  to  elevate  the  relative  impor- 
tance of  data  organization  (Jackson  75)  . The  evidence  that 
emerqes  from  the  present  study  is  that  SCM  is  inherently 
quite  compatable  with  this  more  balanced  view  of  the  impor- 
tance of  both  processing  and  data  interrelationships  in  det- 
ermining good  system  structure. 
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Finally,  a few  other  requirements  fall  into  this  sub- 
problem because  they  specify  reporting  needs  that  would  be 
met  primarily  using  data  common  to  other  requirements  of  the 
same  subproblem.  Included  here  are  requirements  34,  36,  40, 
41,  and  42.  All  five  of  these  statements  refer  to  potential 
reportinq  requirements  of  various  types  that  all  would  most 
likely  involve  budget  and  actual  operational  data  common  to 
other  requirements  in  this  subproblem. 

In  summary,  while  Subprofclem  2 is  a fairly  large  sub- 
problem,  careful  study  indicates  that  the  19  requirements  do 
"hanq  together"  for  design  purposes,  largely  as  a result  of 
their  common  data  implications. 

SubProblt  m 3 - Pat  abase  Access  for  Nonstandard  Report  Gcner- 

The  third  subproblem  contains  13  requirements.  The 
focus  of  this  subproblem  is  database  access  for  purposes 
other  than  standard  report  generation.  This  includes 
requirements  for  users'  ad-hoc  access  (requirements  44  and 
45) t users'  access  via  the  report  writing  facility  (require- 
ments 43  and  46) , and  access  to  the  Budgeting  System's  data- 
bases via  other  systems  (requirement  16).  This  subproblem 
also  includes  certain  database  security  requirements  that 
pertain  to  user  access,  namely,  requirement  47  through  52. 
These  requirements  all  relate  to  data  ownership  and  data 
element  controls  that  are  closely  related  to  data  ownership. 


Since  these  security  issues  manifest  themselves,  in  imple- 
mentation terms,  primarily  at  the  point  of  data  access,  it 
makes  very  qood  sense  that  they  be  grouped  together  with 
other  data  access  requirements. 

The  presence  of  requirement  74  in  this  subproblem  also 
makes  qood  sense:  formal  training  issues  would  undoubtedly 
be  heavily  concerned  with  data  access,  as  this  would  be  the 
main  interest  of  most  users.  An  interesting  side  point 
reqardinq  this  requirement  is  that,  at  first  glance,  it  may 
not  appear  to  be  a desiqn-relevant  issue  at  all.  This  ques- 
tion was  in  fact  debated  among  the  system  designers  and  the 
SDS  researcher,  with  (eventually)  the  opposite  conclusion. 
The  main  argument  ran  as  follows.  There  is  no  requirement 
statinq  that  the  system  (specifically,  access  to  data)  be 
"easy  for  users  to  use,"  Such  a requirement  would  be  too 
qeneral,  at  too  high  an  abstraction  level,  to  be  appropriate 
for  SDH  analysis.  In  contrast,  requirement  74,  specifying 
the  need  for  formal  user  training,  is  more  specific,  at  an 
abstraction  level  comparable  with  the  other  requirements, 
and  at  the  same  time  achieves  most  of  the  saino  results.  In 
thinkinq  about  how  one  miqht  "implement"  a requirement  such 
as  74,  one  is  led  to  imagine  what  a trainer  would  have  to 
say  to  explain  various  aspects  of  system  functioning  thought 
to  be  of  interest  to  different  user  groups.  Thinking  in 
this  way  leads  the  system  designers  to  adjust  their  concep- 
tual models  of  implementation  for  the  associated  require- 
ments, with  an  eye  to  the  need  foe  formal  teaming. 
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Finally,  requirement  64  (support  for  current  budgeting 
techniques)  also  ended  up  in  Subproblem  3.  The  case  for 
this  requirement  being  in  this  subproblem  is  not  obvious 
initially.  However,  a review  of  the  "audit  trail"  of  inter- 
dependency assessments  indicates  that  requirement  64  was 
found  to  be  interdependent  with  only  two  other  requirements: 
weakly  with  32  (Subproblem  2),  and  with  average  strength 
with  requirement  74  (Subproblerr  3).  Its  ending  up  in  the 
present  subproblem  is  therefore  justifiable  on  purely 
"mechanical"  grounds.  The  rationale  for  its  interdependency 
with  74  concerns  user  training.  Formal  training  on  the  one 
hand,  and  support  for  all  budgeting  methods  on  the  other, 
are  seen  to  be  discordant  requirements.  Through  this  line 
of  reasoning  one  can  envision  second-order  relationships 
between  64  and  many  of  the  other  requirements  in  Subproblem 
3,  bearinq  on  the  fact  that  a multitude  of  budgeting 
approaches  would  probably  make  the  implementation  of  user 
access  to  data,  and  control  of  data,  more  difficult  to 
achieve.  Clearly,  users  may  require  access  to  different 
data  combinations  under,  say,  line  item  budgeting  than  they 
would  under  program  budgeting.  However,  the  fact  remains 
that  requirement  64  is  only  tangentially  concerned  with  the 
main  focus  of  Subproblem  3,  but  as  it  is  no  "closer"  to  any 
other  subproblem,  it  ended  up  there. 


Subproblem  4 - Physical  Keport  Handling . 

This  subproblem  only  contains  two  requirements,  and  is 
therefore  rather  easy  to  interpret.  Its  focus  is  physical 
report  handlinq.  One  requirement  (15)  concerns  the  report 
medium,  specifying  that  reports  will  be  physically  easy  to 
handle.  In  implementation  terms,  this  may  be  viewed  as 
arguinq  aqainst  the  production  of  reports  on  standard  11x14 
inch  computer  paper,  and  suqqests  the  use  of  Q 1/2  x 11  inch 
paper  for  reports.  In  fact,  this  requirement  is  an  example 
of  a situation  discussed  earlier:  the  designers*  original 
requirement  statement  (see  Appendix  H,  requirement  7)  actu- 
ally specified  the  way  in  which  this  requirement  could  be 
achieved,  i.e.,  contained  within  it  its  own  implementation 
approach.  In  the  spirit  of  SEM  analysis,  the  requirement 
was  re-written  so  as  to  be  functional  in  form,  and  implemen- 
tation-free. However,  as  the  designers  did  not  want  to  lose 
sight  of  their  implementation  concept  (and  indeed  wanted 
other  readers  of  the  requirement  statements  to  be  aware  of 
it  also)  they  decided  to  keep  it,  in  the  form  of  a comment 
on  requirement  15  (Appendix  C)  . 

The  other  requirement  in  this  subproblem,  77,  simply 
says  that  the  new  Budgeting  system  should  be  designed  so  as 
to  minimize  unnecessary  delay  in  report  production  and  dis- 
tribution. A discordant  interdependency  between  require- 
ments 15  and  17  occurs  because  one  way  of  meeting  77  would 
be  to  employ  a number  of  RJE  terminals  or  remote  printers  at 
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usee  sites;  but  this  would  likely  result  in  reports  being 
printed  on  larqe  forms,  thereby  counteracting  requirement 

15. 


Subprob lem  5 - Use  of  EFT  to  Define  Personnel  Levels. 

Subproblem  5 contains  three  requirements,  and  is 
straightforward  to  interpret.  The  central  focus  for  this 
subproblem  is  the  use  of  EFT  ("effective  full-time")  units 
for  dealinq  with  personnel  data.  The  idea  is  that  many 
administrative  officers  (AO's)  find  it  easier  to  think  in 
terms  of  EFT  units  for  personnel  budgets  than  in  dollar 
terms,  hence  requirement  9 specifies  that  EFT  may  in  fact  be 
employed  to  develop  personnel  budgets.  However,  as  budgets 
are  necessarily  framed  eventually  in  dollar  terms,  there 
must  be  a mechanism  within  the  Budgeting  System  for  convert- 
ing between  EFT  and  dollars.  This  is  not  as  simple  a task 
as  it  may  at  first  appear;  a number  of  detailed  issues  have 
to  be  considered,  and  the  conversion  algorithms  may  be 
rather  complex. 

Finally,  requirement  13  specifies  the  need  for  flexi- 
bility in  manpower  reporting  (as  opposed  to  budgeting) . In 
practice  it  is  easier  to  report  some  types  of  manpower  in 
man-months,  other  types  in,  say,  man-hours,  etc.  Clearly, 
allowing  such  reporting  flexibility  complicates  still 
further  the  dollars-EFT  conversion  issue,  hence  this 
requirement's  presence  here. 
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Su  bp  rob  loin  6 - Maintenance  of  Database  Integrit  y 


Control 


This  subprobleir  includes  six  requirements,  and  has  as  a 


central  focus  the  maintenance  of  database  integrity  and  con 


trol.  requirements  53,  54,  55,  and  67  all  relate  directly 


It  should  be  noted  that 


these  requirements  impact  system  design  primarily  in  the 


choice  of  a commercial  DBMS  to  be  used  as  the  heart  of  the 


new  system,  as  there  is  no  intent  in  the  minds  of  the  desig 


ners  to  develop  their  own  underlying  data  management  soft 


ware 


Requirements  69  and  70  pertain  to  computerized  funds 


drafts  beinq  performed,  either  on-line  or  via  batch  transac 


Once  again,  these  requirements  might  appear  to  be 


tion 


rather  distant  from  the  preceding  four.  Clo 


er  examination 


dispels  this  notion,  and  confirms  again  the  correctness  of 


the  partitioning.  Funds  drafting,  and  the  checking  and  ver 
ification  thereof,  is  perhaps  the  most  sensitive  data-han- 


dlinq  aspect  of  the  new  system,  as  it  deals  directly  with 


the  movement  and  control  of  real,  spendable  credits.  (5) 


Therefore  the  requirements  to  allow  electronic  funds  draft 


inq  in  the  new  system  are  especially  closely  related  to  the 


integrity  concerns,  notably  the  audit  trail  requirement 


In  implementing  tne  integrity  requirements,  vury 


close  attention  will  also  have  to  be  paid  simultaneously  to 


the  funds  drafting  issue 


(5) most  of  the  system's  databases  will  consist 
data,  or  else  real  expense  (credit)  data. 


The  separation  of  requirements  69  and  70  from  other 
requirements  dealing  with  funds  (see  Sufcproblem  10)  is 
another  qood  example  of  t ho  issue  discussed  on  page  J4,  con- 
cerning the  need  to  carcLully  different iato  between  require- 
ments that  are  logica 11 v related  (c.g.,  all  requirements 
dealing  with  funds) , and  those  that  are  related  in  implemen- 
tation terms. 

Subprob lem  7 - Organization  o f Budget ing/Accou nt ing  Objects. 

This  subproblem  includes  three  requirements.  The  sub- 
problem's  focus  is  the  organization  of  the  budget- 
inq/accounting  "objects."  This  term  has  an  unambiguous 
meaning  to  the  budgeting  and  administrative  staff  of  the 
Institute.  "Objects"  represent  one  way  of  organizing  the 
elements  of  income  and  expenditure  of  the  Institute;  for 
instance,  "secretarial  salaries"  might  be  an  expenditure 
object,  while  "federal  qrants"  might  be  a revenue  object. 

In  the  present,  budgeting  system,  there  is  a fixed  set  of 
objects,  and  codes  for  each  object,  with  which  all  concerned 
must  work.  (6)  , 

The  new  system,  as  these  requirements  indicate,  is  to 
have  greater  flexibility  in  terms  of  object  definition. 
Specifically,  it  will  be  possible  to  define  multiple  hierar- 
chies of  objects.  Also,  departments  will  be  able  to  define 


their  own  personal  objects  within  the  central  system 


» 


The  three  requirements  of  this  subproblcm  are  clearly 
related  quite  closely  for  implementation  purposes.  In  par- 
ticular, it  may  be  noted  that  the  requirements  for  multiple 
object  hierarchies  (11  and  12)  probably  rule  out  the  possi- 
bility of  usinq  a hierarchically-oriented  commercial  DBMS 
such  as  IBM's  Information  Management  System  (IBM  74)  for  the 
system's  database  manaqer. 

S nbproblen  8 - Development  and  Management  of  Planning  Data. 

This  subproblem  contains  four  requirements,  and  has  as 
its  focus  the  development  and  management  of  Institute 
intermediate-range  planning  data.  Planning  data  differs 
from  budqet  data  in  a number  of  ways.  First,  its  develop- 
ment is  neither  homogeneous  nor  universal  across  the  Insti- 
tute. Some  departments  develop  much  more,  and  more  highly 
detailed,  planning  data  than  do  others;  some  plan  up  to  two 
years  ahead,  others  up  to  three  years,  still  others  five 
years  out.  Also,  the  nature  of  the  data  differs  from  budget 
data,  often  being  more  in  the  form  of  descriptions  of  under- 
lying qoals,  directions,  etc.,  for  a given  department., 
rather  than  hard  numbers  at  a relatively  fine  level  of 
detail. 


During  their  analysis  of  the  present  planning/budgeting 
practice,  the  Budget  System  designers  found  a need  for  some 
level  of  automated  assistance  to  t.he  planning  function  of 


various  administrative  staff.  Since  this  function  is  fairly 
closely  related  to  the  budgeting  function,  to  include  some 
planninq  assistance  capabilities  in  the  nen  system  seemed 
appropriate.  Requirements  5 and  6 address  the  planning  data 
issue  directly.  Requirement  35  concerns  data  requirements 
for  the  '‘Dynamic  Model"  - M.I.T.’s  financial  forecasting 
model.  Since  many  of  the  model's  data  requirements  are  in 
the  nature  of  planning  data,  it  is  appropriate  that  this 
requirement  fall  in  the  current  subproblem.  Specifically, 
the  determination  of  the  type  of  planning  data  to  be 
obtained  from  the  Institute  managers  ought  to  be  influenced 
directly  by  the  data  needs  of  the  model. 

The  inclusion  of  requirement  27  in  this  subproblem  is 
another  instance  of  a surprisingly  intelligent  outcome  of 
the  SDfl  decomposition.  While  logically  related  (in  the 
sense  discussed  on  page  34  ) to  requirements  21  through  26, 
this  requirement  differs  on  one  very  important  respect: 
historical  actual  data  is  the  key  database  referenced  by 
managers  and  administrators  in  drawing  up  their  intermedi- 
ate-ranqe  plans.  None  of  the  other  requirements  21-26  have 
this  property.  The  implementation  of  planning  assistance 
facilities  in  the  new  Budgeting  System  must  take  into  con- 
sideration both  what  planning  data  will  be  captured,  and 
what  data  will  be  required  by  managers  in  developing  their 
plans.  Requirements  5 and  6 correspond  to  the  former  con- 
cern, requirement  27  to  the  latter. 
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Sa-feBIobiSiT  9 - Em£loj£oe  Benefit  Rate  Calculations. 


This  subproblem,  with  three  requirements,  concerns 
employee  benefit  rate  calculations.  In  •the  present  budget- 
inq  system,  management  or  employee  benefits  may  present  some 


especially  when  a)  amounts  budgeted  for  per 


complexities 


sonncl  expenses  are  used  for  non-personnel  expense  items, 
and  vice  versa;  b)  dollar  budgeting  blanket  adjustments  are 


made,  such  as  changing  the  rate  of  benefits  as  a percent  of 


salary;  and  c)  when  non-standard  employee  benefit  rates  must 


be  applied  due  to  contract  provisions,  retroactive  changes. 


mismatchs  of  fiscal  years,  etc 


A typical  example  of  these  problematic  issues  might 


involve  a department's  budget  that  is  approved  given  a cer 


tain  staffing  profile.  That  profile  may  then  be  altered 


through  substitution  of  certain  staff  members  for  others 


(c.q.,  increasing  the  number  of  individuals  assigned  to  a 


particular  research  project) . This  kind  of  change  may 


require  a compensating  change  in  employee  benefit  amounts 


being  charged  to  that  department 


sent,  frequently  "lost  in  the  shuffle."  Subproblem  9 


addresses  the  need  for  an  effective  mechanism  for  control! 


ing  the  employee  benefit  issue  within  the  Current  and  Future 


budgets 


Since  employee  benefit  amounts  are  a percentage  of  per 


sonnel  salaries  and  waqes,  it  makes  good  sense  that  require 
ment  8 be  included  in  this  subproblem.  Similarly,  require- 


AVI 


meat  75  is  concerned  with  handling  non-standard  employee 
benefits  (e.q.,  benefits  for  a part-time  faculty  member), 
which  are  subject  to  very  similar  needs  for  control  as  are 
standard  benefits. 

Subprob  1cm  - Organ izat ion  and  Management  of  Fund 

As^aants. 

There  are  seven  requirements  in  Subproblem  10.  The 
focus  of  this  subproblcm  is  the  organization  and  management 
of  fund  accounts.  At  the  heart  of  this  design  subproblem  is 
requirement  30,  "...facilitate  the  effective  use  of  funds 
accounts."  The  other  requirements  in  this  subproblem  (with 
one  exception,  to  be  explained  shortly)  all  partially  derive 
from  requirement  30.  Requirements  1,  2,  and  3 all  specify 
alternative  ways  in  which  fund  data  may  be  organized  (and 
hence  retrieved  during  queries,  etc.).  Requirement.  4 
addresses  the  need  to  supply  adequate  descriptive  informa- 
tion for  each  fund  account  within  the  database  itself. 
Requirement  37  pertains  to  reporting  standard  fund  informa- 
tion. Finally,  requirement  17  specifies  the  need  for  access 
to  data  in  the  databases  of  other  Institute  DP  systems.  The 
system  designers  saw  this  as  closely  associated  with  effec- 
tive fund  management,  largely  because  much  of  the  informa- 
tion that  would  be  needed  in  order  for  requirement  30  to  be 
properly  implemented  resides  in  the  Gift  System.  (7)  A direct 


(7)This  is  the  system  that  is  used  to  manaje  gifts, 

bequests,  etc. 
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link  to  the  latter  system  would  be  superior  to  duplicating 
and  separately  maintaining  the  necessary  databases. 


Subproblem  1 1 - Database  Expandability. 

The  £inal  subproblem  contains  two  requirements,  and  its 
focus  is  database  expandability.  Specifically,  requirements 
72  and  73  state  that,  unlike  the  present  budgeting  system, 
the  new  system  will  allow  new  data  elements  to  be  defined 
within  oblects  or  accounts,  in  order  to  provide  additional 
flexibility  and  usefulness  for  the  system's  users.  For 
instance,  one  department  may  wish  to  summarize  a certain  set 
of  account  balances  in  a unique  way.  The  new  system  would 
allow  a special  data  item  to  be  defined  to  hold  the  appro- 
priate summary  data,  and  also  to  tie  the  new  item  logically 
to  the  lower-level  items  it  summarizes,  so  that  when  changes 
are  made  to  the  lower-level  items  the  summary  item  will  also 
be  updated.  (8)  This  requirement  ties  into  the  concept  of 
loqical  data  independence  that  has  come  to  prominence  along 
with  the  use  of  database  management  systems  (Martin  77). 

* * * * * 

This  concludes  the  analysis  and  interpretation  of  the 
eleven  identified  system  design  subproblems.  The  subprob- 
lems and  their  interpretations  are  summarized  in  Table  4.2. 
In  the  next  section  we  analyze  the  interrelationships  (sets 
of  interdependencies)  between  the  various  subproblems.  The 


(8)either  actually  or  virtually  - see  (Folinus,  ct.  al.  76). 
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Subpcob  lem 


Description 


1 Preparation  of  budget  proposals 

2 Operations  reporting 

3 Database  access  for  purposes  other  than 
standard  report  generation 

4 Physical  report  handling 

5 Use  of  EFT  to  define  personnel  levels 

6 Maintenance  of  database  integrity,  control 

7 Organization  of  budgeting/accounting  objects 

8 Development  and  management  of  planning  data 

9 Employee  benefit  rate  calculations 

10  Organization  and  management  of  fund  accounts 

11  Database  expandability 


Table  4.2 

Subproblem  Summary  Descriptions 


combined  interpret.it ion  of  subproblem  and  interrelationship 
analyses  constitutes  the  architecture  interpretation  for  the 
new  Budqetinq  System.  The  final  section  contains  concluding 
comments  pertaining  to  global  aspects  of  this  architecture. 

4.3  ANALYSIS  OF  SUuFhOBLZM  INTERRELATIONSHIPS. 

There  is  a total  of  21  links  interconnecting  the  11 
desiqn  subproblems  in  the  new  Budgeting  System  architecture. 
Some  statistics  regarding  these  links  are  shown  in  Table  4.3 
below.  It  is  shown  there  that  the  average  number  of  inter- 
dependencies per  subproblem  link  is  4.5;  however,  there  are 
only  five  links  consisting  of  more  than  five  interdependen- 
cies. Since  both  number  of  interdependencies  as  well  as 
interdependency  weiqhts  are  important  determinants  of  link 
strenqth,  Table  4.3  also  shows  total  weight  for  each  link. 
This  is  just  the  sum  of  the  weights  on  all  the  interdepen- 
dencies making  up  each  link.  From  this  table  it  may  be  seen 
that  the  distribution  of  link  total  weights  is  as  shown  in 
Fiqure  4.3  below.  From  the  figure,  it  is  clear  that  the 
desiqn  partitioning  has  two  rather  strongly  interconnected 
subproblems  and  (2,10)),  three  subproblem  linkages 

of  medium  strenqth  ((1,10),  (2,3),  and  (2,8)),  while  the 
remaining  subprobleir  linkages  have  a total  weight  of  less 
than  2.0,  so  are  relatively  weakly  connected.  In  the  dia- 
gram of  Fiqure  4.2  earlier,  the  strongest  linkages  are  shown 
shaded,  the  medium-weight  ones  arc  drawn  as  double  lines, 
while  the  remainder  are  shown  as  single  lines. 
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ID  # 

First 

Subproblem 

Second 

Subproblem 

Number  of 
Linking 
Interde- 
pendencies 

Total 

Weight 

Average 

Weight 

1 

1 

2 

20 

7.6 

0.38 

2 

i 

3 

5 

1.9 

0.38 

3 

1 

5 

4 

1.1 

0.28 

4 

1 

6 

3 

1.2 

0.40 

5 

1 

9 

4 

1.4 

0.35  ‘ 

6 

1 

10 

10 

3.8 

0.38 

7 

2 

3 

7 

3.2 

0.46 

8 

2 

5 

2 

1.0 

0.50 

9 

2 

7 

2 

1.3 

0.65 

10 

2 

8 

10 

3.8 

0.38 

11 

2 

9 

2 

1.0 

0.50 

12 

2 

10 

16 

6.8 

0.43 

13 

2 

11 

5 

1.9 

0.38 

14 

3 

4 

1 

0.5 

0.50 

15 

3 

6 

2 

0.7 

0.35 

16 

5 

• 9 

2 

1.3 

0.65 

17 

6 

9 

3 

0.9 

0.30 

18 

6 

10 

3 

0.9 

0.30 

19 

6 

11 

1 

0.5 

0.50 

20 

7 

8 

1 

0.5 

0.50 

21 

10 

11 

1 

0.8 

0.80 

Table  4.3 

Statistics  for  the  Inter-subproblem  Linkages 
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Figure  4.3 

Distribution  of  Link  Total  Weights. 

It  is  worth  recalling  at  this  point  that  the  underlying 
motivation  for  this  entire  SDM  exercise  is  to  formulate  a 
system  architecture  which  exhibits  high  module  strength  and 
low  coupling.  The  objective  function  M , of  course,  is  a 
formal  attempt  to  quantify  that  concept . Informally  and 
judgmental ly , a system  decomposition  with  only  two  rela- 
tively stronqly  interconnected  sufcproblem  pairs,  three  pairs 
with  medium  interconnection  strength,  and  fifteen  with  rela- 
tively weak  interconnection  strength  should  probably  be 
judqed  as  a fairly  good  ore  from  this  point  of  view. 

We  now  examine  each  subproblem  linkage,  and  describe  an 
interpretation  of  the  nature  of,  and  the  reasoning  behind, 
each . 


Linkage  J (Subprobletns  Jl  and  2)  . 

This  is  the  larqest  linkage,  with  a total  link  weight 
of  7.6.  Eleven  of  the  linking  interdependencies  represent 
common  data  issues:  databases  defined,  cither  implicitly  or 
explicitly,  in  conjunction  with  requirements  in  Subproblem  2 
that  are  also  needed  for  effecting  certain  proposal  prepara- 
tion-related requirements  in  Subproblem  1.  This  includes  in 
particular  Chart  of  Accounts  data,  and  Current  and  Future 
Budqet  databases. 

The  remaining  linking  interdependencies  represent  con- 
cordant relationships  that  arise  because  of  common  process- 
ing techniques.  In  one  case,  the  automatic  proration  feature 
may  be  used  to  good  effect  in  proposal  preparation  as  well 
as  operations  monitorinq  activities;  in  the  other  case, 
potential  methods  of  operational  monitoring  facilitate  cer- 
tain aspects  of  monitoring  proposal  preparation. 

Linkage  2 (Subproblems  and  3)  . 

This  linkage  has  a total  weight  of  1.9,  and  includes 
five  interdependencies.  Two  of  the  interdependencies  repre- 
sent the  need  for  training  users  to  use  the  system  for  pro- 
posal preparation.  The  other  three  represent  the  use  of  the 
menu-oriented  query  facility  for  proposal  and  fund  draft 
review  and  checking. 
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This  linkage  consists  of  four  interdependencies,  with  a 
total  weight  of  1,1.  The  coiriron  focus  for  all  four  concerns 
the  ability  of  users  to  prepare  and/or  monitor  the  personnel 
component  of  budqet  proposals  in  the  most  convenient  units 
(typically,  EFT  or  dollars) . 

Linkage  4 (Subproblems  _1  and  6)  . 

This  linkaqe  includes  three  interdependencies,  with 
total  weiqht  1.2.  The  process  of  preparing  budget  proposals 
(Subproblem  1)  requires  administrators  to  access  various 
kinds  of  data  that  will,  in  the  future,  be  available  via  the 
new  system.  The  focus  of  this  linkage  concerns  the  imple- 
mentation issues  surrounding  protecting  the  security  and 
integrity  (Subproblem  6)  of  the  data  that  will  be  accessed 
for  proposal  preparation  purposes. 

Linkaqe  5 (Subproblems  J and  9) . 

This  linkage  includes  four  interdependencies,  and  has  a 
total  weight  of  1.4.  These  interdependencies  all  pertain  to 
the  role  of  employee  benefit  calculations  in  the  proposal 
preparation  process. 
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Linkage  b (Subproblems  J and  JO) . 

This  linkage  contains  1C  interdependencies,  and  has  a 
total  veiqht  of  3.8.  Subproblem  1 addresses  budget  proposal 
preparation  generally,  and  the  requirements  within  Subprob- 
l^m  1 that  connect  to  Subproblem  10  are  concerned  specifi- 
cally with  the  role  that  funds  play  in  proposal  preparation. 
Subproblem  10  focuses  on  the  orgainzation  and  use  of  fund 
accounts.  Good  information  is  the  key  to  better  management 
of  Institute  funds  (gifts,  bequests,  etc.) . At  the  present 
time  fund  monies  are  frequently  not  used  to  their  greatest 
benefit,  because  individuals  who  make  expenditure  decisions 
haven't  been  informed  of,  and  have  no  easy  way  of  discover- 
ing, the  existence  of  certain  funds  whose  designation  meets 
their  needs.  The  intention  in  the  new  Budgeting  System  is 
to  make  fund  purpose  information  readily  available  to  users, 
and  to  otherwise  orient  the  reporting  and  control  of  fund 
data  so  as  to  make  more  effective  use  of  fund  monies.  This 
would  conserve  general  monies  to  more  fully  meet  the  needs 
to  which  funds  do  not  apply. 

Linkage  2 (Subproblems  2 and  3) . 

This  linkage  contains  seven  interdependencies,  with 
total  veiqht  of  3.2.  All  seven  interdependencies  have  a 
fairly  stronq  common  focus:  they  all  represent  techniques  to 
allow  users  to  access  data  in  a manner  other  than  via  stan- 
dard reports  (special  reports,  ad  hoc  queries,  etc.). 
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Linkage  8 (Subproblems  2 and  5) . 

There  are  two  interdependencies  making  up  this  linkage, 
with  a combined  weight  of  1,0.  The  focus  of  these  interde- 
pendencies is  the  proration  of  personnel  budgets  for  the 
production  of  periodic  operating  reports. 

Linkage  2 (Subproblems  2 and  7)  . 

This  linkage  includes  two  interdependencies,  with  a 
combined  weiqht  of  1.3.  It  focuses  on  the  use  of  a hier- 
archical organization  of  object  codes  for  facilitating  the 
production  of  special  reports. 


I 

i 

I 


14 


Linkage  _1^  (Sub problems  2 and  8)  . 

This  linkage  contains  ten  interdependencies,  with  a 
total  weight  of  3.8.  All  of  these  interdependencies  have  a 
clear  common  focus,  namely,  data  commonality  between 
requirements  for  operations  reporting  (Subproblem  2)  and  for 
planninq  (Subproblem  8).  Although  as  pointed  out  earlier, 
planning  data  and  budgeting  data  is  not  identical,  tnere  is 
enough  commonality  to  generate  numerous  imp  lement  at.  ion- level 
interdependencies.  For  instance,  some  of  the  data  required 
by  the  Dynamic  Model  (requirement  35  in  Subproblcm  8)  may  be 
obtained  from  various  managers'  Future  dudgets  (require- 
ment 22,  Subproblem  2)  databases. 
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lilllk^ae  12  (^uhjxohlorns  2 and  9)  . 


This  linkage  contains  two  interdependencies,  with  total 
weight  1.0.  Its  focus  is  the  data  management  issues  common 
to  Future  Budget  personnel  data. 


L inka  go  12  (Subprohloms  2 and  1 0) . 

This  linkage  contains  16  interdependencies,  with  a 
total  weight  of  6.8.  All  of  the  interdependencies  within 
this  linkaqe  concern  different  aspects  of  data  access  com- 
monality between  the  two  subproblems.  Sight  of  the  interde- 
pendencies focus  on  databases  common  to  ad  hoc  retrieval 
requests  associated  with  operations  monitoring,  and  similar 
requests  associated  with  funds  management.  Another  four 
interdependencies  are  related  to  databases  common  to  opera- 
tions monitoring,  and  to  making  effective  use  of  fund 
accounts.  Another  three  relate  to  similar  databases  common 
to  standard  report  generation  for  operations  monitoring  and 
for  fund  management.  Finally,  one  of  the  interdependencies 
represents  the  common  need  for  access  to  other  systems'  data 
files. 

Linkage  1 3 (Subnroblems  2 <jnd  J2 J . 

This  linkage  represents  five  inter  dependencies,  with  a 
total  weiqht  of  1.9.  All  five  inter dependencies  porta  in  to 
the  application  of  the  facility  tor  adding  new  data  item 
types  to  currently  existing  databasts,  to  tho  development  of 
operations  monitoring  requirements. 
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_lii  (Sub  p cob  loins  3 and  4)  . 


There  is  a single  interdependency  in  this  linkage,  with 
a weight  of  0.5,  The  focus  of  this  link  is  mechanisms  for 
speedinq  the  delivery  of  Budgeting  System  information,  in 
the  form  of  standard  reports,  to  system  users, 

linkage  J. 5 (Sub problems  3 and  6)  . 

There  are  two  interdependencies  within  this  linkage, 
with  a total  weight  of  0.7,  Their  common  focus  is  the 
maintenance  of  database  integrity  and  security  by  means  of  a 
transaction  logging  technique. 

iili&age  .16  (Subproblcms  5 and  9)  . 

There  are  two  interdependencies  in  this  linkage,  with  a 
total  weight  of  1.3.  Their  common  focus  is  the  conversion 
of  personnel  data  between  dollars  and  EFT. 

linkage  17  (Subproblems  6 and  9)  . 

This  linkage  includes  three  interdependencies,  with 
combined  weight  0.9.  Their  focus  is  audit  trail  maintenence 
in  the  face  of  automatic  system  updating  of  certain  data 
items . 


linkage  19  (Subjjrobleins  6 and  JO)  . 

This  linkaqe  includes  three  interdependencies,  total 
weight  of  0.9.  They  all  focus  on  the  effecting  of  computer- 
based  funds  drafting. 

Linkage  19  (Subpr oblems  6 and  1 1)  . 

This  linkage  consists  of  a single  interdependency, 
total  weight  0.5.  The  linkage  concerns  the  implementation 
of  a data  chanqe  log  in  a restructurable  database. 

Linkage  2_Q  (Suhproblems  7 ami  8)  . 

This  linkage  contains  a single  interdependency,  with  a 
weiqht  of  0.5.  It  concerns  the  use  of  the  object  hierarchy 
for  organizing  the  development  of  planning  data  for  the 
Dynamic  Model. 

Linkage  2J  (Snbprobleirs  1 0 and  JU)  . 

The  final  linkage  also  includes  but  one  interdepen- 

i 

dency,  with  a weiqht  of  0.8.  Its  focus  is  the  addition  of 
fund  purpose  categorization  information  to  the  funds 
accounts . 

* * * * * 

This  completes  the  description  of  the  individual  link- 
ages between  the  design  subproblems.  Summary  descriptions 
of  the  21  inter-subproblerr  linkages  are  given  in  Table  4.4. 


Figure  4.4  shows  a complete  description  of  the  SDM-der- 
ived  architecture  for  the  new  Budgeting  System.  Each  design 
subproblem  and  linkage  is  labelled  in  an  abbreviated  fash- 
ion, based  on  the  descriptions  given  in  Tables  4.2  and  4.4. 

In  the  final  section  of  this  report  we  briefly  discuss 
certain  broad  issues  that  arise  out  of  this  architecture. 

He  also  summarise  there  the  work  to  date  and  suggest  some 
areas  for  further  research. 
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1 


ID 

Su  bqraphs 

Summary  Description 

1 

1.2 

common  databases;  common  processing 
viz.  proration,  monitoring. 

2 

1»  3 

training  in  proposal  prep,  use;  proposal/ 
fund  draft  review  and  checking  via  guery. 

3 

1,5 

alternative  units  for  personnel  data. 

4 

1,6 

protection  of  the  security  and  integrity 
of  proposal  preparation  data. 

5 

1.9 

employee  benefit  calculations  in  pro- 
posal preparation. 

6 

1,  10 

effective  use  of  funds  in  proposal  preparation. 

7 

2,3 

data  access  for  nonstandard  usage. 

8 

2,5 

personnel  data  proration  in  periodic  rpts. 

9 

2,7 

use  of  hierarchical  object  organization  in 
production  of  special  reports. 

10 

2,8 

operations  reporting  and  planning  data 
commonality . 

1 1 

2,9 

common  Future  Budget ing/Personncl  Budgeting 
data  management  issues. 

12 

2,10 

data  commonality:  ad  hoc  retrieval,  monitor- 
ing standard  reporting,  other  systems. 

13 

2,11 

extension  of  operations  monitoring  data  files. 

14 

3,4 

prompt  report  delivery. 

15 

3,6 

use  of  logging  to  effect  database  integrity 
and  security. 

16 

5,9 

conversion  of  personnel  data:  dollars  vs.  EFT. 
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17 

6,9 

maintenance  of  audit  trail  in  face  of  auto 
updating  of  data  elements. 

18 

6,  10 

effecting  computer-based  funds  drafting. 

19 

6,  11 

maintenance  of  change  log  when  database 
structure  is  modified. 

20 

7,8 

hierarchy  of  object  codes  used  to  effect 
generation  of  Dynamic  Model  data. 

21 

10,11 

addition  of  fund  purpose  categorization 
data  to  fund  accounts. 

Table  4,4 

Summary  Description  of  the  Sufcproblem  Linkages. 


5.  CONCLUSIONS. 


The  original  objectives  of  this  study  were  threefold: 


to  study  the  application  of  the  Systematic  Design 
Methodology  in  a real,  ongoing  design  context; 


to  study  the  reactions  of  a group  of  real(S)  sys- 
tem designers  to  the  methodology,  to  begin  to 
learn  their  views  of  its  usefulness,  effective- 
ness, etc. 


to  assist  the  Budgeting  System  design  team  in  con- 
structing an  architecture  for  this  new  system. 


As  for  the  first  point,  the  various  steps  of  the  S DM  were 


able  to  be  executed  with  little  difficulty.  As  reported 


earlier,  a substantial  amount  cf  time  was  spent  initially  in 


preparing  the  requirement  statements.  Also,  the  interdepen- 


dency analysis  phase  consumed  quite  a bit  of  meeting  time. 


However,  the  decomposition  analysis  and  architectural 


interpretation  were  both  relatively  straightforward,  and  not 


particularly  time  consuming.  This  suggests  that  the  time 


and  effort  invested  early  in  the  SDM  effort  pays  off  in 


terms  of  a "good”  initial  decomposition  and  easily  inter- 


pretable architecture  later  on. 


Such  an  observation  is  in  general  agreement  with  what 


other  software  design  researchers  have  found  in  other  con- 


texts. Boehm,  for  instance,  has  estimated  on  the  order  of  a 


(9) as  opposed  to  SDM  researchers  playing  the  role  of  system 
designers 
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3-to-1  payback  to  additional  time  invested  in  early  design 
activities  (Boehm  75) . Also,  the  truth  of  this  observation 
in  the  SDH  context  is  verified  by  earlier  applications  car- 
ried out  by  other  SDH  researchers.  Andreu  (Andreu  77(a)) 
applied  SDH  to  the  design  of  a database  management  system. 

He  adopted  a set  of  government-issued  DBMS  requirement 
statements  for  use  in  his  design.  His  first  pass  at  build- 
ing a system  architecture  resulted  in  a rather  unsatisfac- 
tory decomposition,  with  a few  large,  unwieldy,  hard-to-in- 
terpret  subproblems.  After  "completing  the  requirements 
set"  by  studying  the  requirements  statements  carefully  for 
missing  requirements,  ambiguous  statements,  etc. , and  making 
a number  of  additions  and  modifications,  a second  decomposi- 
tion resulted  in  what  Andreu  argued  was  a much  better  archi- 
tecture - smaller,  more  coherent  subproblems  arranged  in  a 
fashion  he  found  much  easier  to  interpret. 

In  contrast,  in  the  present  study  we  spent  much  more 
time  in  framing  and  refining  the  original  requirement  state- 
ments. In  fact,  the  requirement  specifications  upon  which 
the  SDH  statements  were  based  was  the  result  of  over  a year 
of  study,  analysis,  interviews,  etc.  Also,  the  SDM  version 
of  the  statements  was  given  reasonable  in-depth  study  over  a 
number  of  iterations  by  both  the  system  designers  and  the 
SDH  researcher.  It  is  most  likely  for  this  reason  that  the 
requirements  decomposition  and  resulting  architecture  turned 
out  to  be  as  good  as  it  did  after  a single  "pass"  of  the  SDH 
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analysis.  With  very  fe¥  exceptions  (to  be  discussed  below) 
the  desiqn  subproblems  and  linkages  were  clear  and  easy  to 
interpret.  All  subproblems  were  found  to  have  an  obvious 
desiqn  focus,  as  described  earlier.  Similarly,  the  impor- 
tant desiqn  implications  of  the  various  inter-subproblem 
linkaqes  were  easily  identified.  Judged  by  this  mixture  of 
intuitive  and  explicit  measures,  SDH  functioned  well  in 
quidinq  us  to  the  identification  of  a good  architecture  for 
the  new  Budqetinq  System. 

The  second  point  concerns  reactions  of  the  Budgeting 
System  desiqners  to  SDH.  They  expressed  both  positive  and 
negative  reactions  to  the  analysis  exercise,  all  of  which 
were  discussed  earlier  (see  Section  3.J).  In  summary,  the 
main  neqative  reactions  concerned  the  time  required  for  the 
analysis,  and  some  uncertainty  about  the  overall  value  of 
the  exercise  (the  latter  occurred  mostly  at  the  outset). 
Both  issues  were  tempered,  of  course,  by  an  appreciation  of 
the  research  nature  of  the  study.  The  positive  reactions 
concerned  new  design  ideas,  as  well  as  clarification  and 
improvement  of  current  ideas,  that  emerged  during  the  exer- 
cise; discovery  of  new  ways  of  approaching  the  design  task 
in  qeneral  (e.q.,  separation  of  functional  concerns  from 
implementation  issues);  and  their  belief  that  the  final 
architecture  would  be  of  assistance  in  the  later  detailed 
desiqn  efforts. 
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As  for  the  final  point,  the  eventual  value  of  the  Budg- 
eting System  architecture  presented  in  the  preceding  section 
cannot  be  known  at  this  time.  Rather,  it  will  be  necessary 
for  the  SDM  researchers  to  follow  up  this  exercise  in  the 
future  to  learn  what  kind  of  impact  this  study  might  promul- 
gate. 

The  study  has  provided  a number  of  other  insights,  many 
of  wnich  were  mentioned  earlier  in  this  report.  The  most 
important  of  these  are  summarized  below. 

1.  The  design  architecture  that  emerged  from  our  work 
did  prove  to  be  relatively  "clean"  (high  strength, 
low  coupling).  however,  a few  minor  points  might 
bear  additional  investigation  by  the  system  desig- 
ners, For  instance,  requirement  64  was  found  not 
to  have  an  obvious  "home"  in  any  subproblem.  This 
may  suggest  that  either  certain  interdependencies 
between  it  and  other  requirements  were  missed  dur- 
ing the  earlier  analysis,  or  possibly  that  other 
requirements  more  closely  associated  with  require- 
ment 64  are  missing  from  the  requirement  set. 

2.  A second  minor  decomposit ion  issue  concerns  the 
size  of  Subproblem  2.  As  discussed  in  Section  4.2 
earlier,  there  are  good  reasons  for  the  relatively 
broad  scope  of  this  subproblem.  The  operations 
reporting  function  is  central  to  the  Budgeting 


System,  hence  we  should  expect  this  subproblem  to 
encompass  a larqer  collection  of  requirement 
statements  than  many  of  the  others.  The  central- 
ity of  the  subproblem  is  further  evidenced  by  not- 
ing that  it  has  eight  linkages  to  other  subprob- 
lems - substantially  more  than  any  of  the  others 
(see  Figure  4.4).  The  centrality  of  this  subprob- 
lem should  serve  as  a signal  to  the  system  desig- 
ners that  perhaps  the  detailed  design  ought  to 
also  center  on  the  implementation  of  these 
requirements.  Also,  in  general  the  presence  of  a 
large  subproblem  such  as  this  in  a decomposition 
should  bo  carefully  studied,  as  it  may  suggest 
possible  improvements  to  the  decomposition. 

Andreu  found  the  occurrence  of  especially  large, 
heterogeneous  subproblems  to  be  "caused"  by  in 
incomplete  or  poorly  framed  requirements  set. 

Also,  it  could  be  that  certain  interdependency 
assessments  are  missing  or  in  error.  While  they 
will  not  be  further  investigated  here,  these  pos- 
sibilities are  worth  some  study  by  the  system 
designers  in  the  future. 


A third  summary  point  is  that  the  SD.1  techniques 
used  in  this  study  seemed  to  function  rather  well. 
The  use  of  a three-way  breakdown  for  specifying 
interdependency  weights  should  be  judged  quite 
effective  in  practice:  a threefold  distinction 
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could  be  made  easily  by  the  designers,  and  the 
need  for  finer  detail  rarely  arose.  Other  mechan- 
isms - the  interdependency  data  form,  use  of 
WSCRIPT  to  manaqe  the  requirement  statements,  etc. 
- worked  well.  The  decomposition  package  also 
functioned  effectively.  A number  of  ideas  for 
marqinal  improvements  to  the  package  arose  in  the 
course  of  its  application  to  the  Dudgeting  System 
problem,  but  these  will  not  be  elaborated  on  here. 

4.  One  lesson  that  came  through  quite  clearly  in  this 
exercise  is  the  important  role  data  linkages  play 
in  determining  requirement  interdependencies  in 
this  kind  of  system  design.  In  a number  of  cases, 
part  or  all  of  the  common  implementation  issues 
tying  a set  of  requirements  together  within  a sub- 
problem were  common  databases  required  for  their 
implementation.  Also,  such  data  commonality 
formed  the  basis  of  the  linkage  between  various 
sub problems.  It  is  interesting  to  note  that  in 
the  previous  S DM  application  exercises  this  impor- 
tant role  of  data  commonality  was  not  evidenced. 
This  is  not  too  surprising  since  systems  like  the 
Budgeting  System  are  much  more  concerned  with  cap- 
turing, processing,  reporting,  and  otherwise  deal- 
ing with  various  databases  than  would  be  "sys- 
tems" software  such  as  a CMS  or  an  operating 


87 


retrospect,  this  observation  should  serve  to  make 
the  importance  of  database  organization  for  the 
Budgeting  System  stand  out  during  future  design 
and  implementation  work. 

While  still  a research  project,  the  Systematic  Design 
Methodology  is  proving  its  effectiveness  in  aiding  system 
architects  to  organize  and  manage  the  many  and  diverse 
requirements  typical  of  complex  systems  design.  This  study 
has  suggested  new  improvements  that  may  be  made  to  the  meth- 
odology, while  again  confirming  its  fundamental  soundness 
and  value. 
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Appendix  A 

EXAMPLE  OUTPUT  FROM  THE  IBM  C800  PRINTER. 


On  the  following  page  is  a sample  of  the  output  obtain- 
able from  the  IBM  J0OO-type  printer. 
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SAMPLE 


Appendix  D 


INITIAL  BUDGETING  SYSTEM  FUNCTIONAL  REQUIREMENTS  AS  PREPARED 

BY  THE  SYSTEM  DESIGNERS. 


1.  Automate  as  many  manual  procedures  as  feasible  to 
save  time  and  effort 

2.  Provide  in  the  Chart  of  Accounts  the  following  for 
all  fund  accounts: 

a)  Coding  for  Principal  - Endowment,  Quasi-endow- 
ment, or  Term  Endowment 

b)  Coding  for  Income  or  current  funds  - Unres- 
tricted, Restricted,  Designated,  or  Restricted 
and  Further  Designated. 

c)  Update  the  60-character  'Fund  Purpose'  field 

3.  Collect  and  store  planning  data  contributed  by  the 
senior  managers 

a)  Data  must  be  in  reasonably  uniform,  useful  for- 
mat 

b)  Data  should  include  short  range  (Next  fiscal 
year)  and  long  range  ( 3 to  5 years)  plans 

c)  The  report  of  the  senior  managers  contained  in 
the  'Report  of  the  President  and  the  Chancel- 
lor' should  refer  to  and  be  consistent  with  the 
short  range  plan  presented  prior  to  the  begin- 
ning of  the  fiscal  year. 

d)  Planning  data  would  be  available  to  the  Dynamic 
Model  (or  its  replacement) 

4.  Provide  for  collecting,  storing  and  reviewing 
details  of  special  financial  agreements  made  among 
managers.  Details  could  be  picked  up  when  drafts 
are  processed.  These  might  be  input  at  time 
drafts  are  made. 
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5.  Provide  for  budgeting  and  reporting  by  E.F.T.  as 
veil  as  dollars.  An  interface  with  the  Payroll 
System  may  bo  necessary. 

a)  Automate  system  where  possible  so  that  a person 
may  be  budgeted  either  by  E.F.T.  or  dollars  and 
provide  a method  for  one  to  generate  the  other 

b)  Allow  for  either  actual  or  average  salaries  to 
be  used  in  budget  proposals. 

c)  Provide  checks  to  ensure  that  each  person  is 
not  budgeted  more  than  1G0X  S.F.T. 

6.  Provide  for  producing  reports  in  units  of  man- 
weeks,  man-months  or  man-years 

7.  Provide  for  additional  object  codes  to  be  summar- 
ies of  other  object  codes  as  necessary 

a)  Ose  summary  codes  for  subtotals  on  reports  or 
for  reporting  only  these  subtotals 

b)  Explore  usefulness  of  summary  codes  that  would 
correspond  with  Billing  Codes 

8.  Review  object  Code  descriptions  to  ascertain  their 
current  applicability 

9.  Provide  support  for  special  object  codes  for  use 
by  each  department.  The  descriptions  for  these 
codes  would  be  supplied  by  the  using  departments, 
and  they  would  subtotal  to  the  appropriate  summary 
object  codes. 

10.  Reports  must  be  easier  to  handle  and  store.  Both 
the  IBd  3600  and  Xerox  9700  Printers  would  solve 
this  problem  throuqh  the  use  of  8 1/2"  by  11"  size 
paper  without  sacrificing  data  capacity. 

11.  Provide  for  sharing  budget  data  with  users  of 
other  systems  and  for  use  of  the  files  of  other 
systems  by  the  Buogot  System  (e.g.  Gift  System, 
ARS,  Payroll,  Purchasing,  etc.) 

12.  Provide  for  as  much  early  recognition  of  potential 
problems  as  possible  so  that  corrections  can  be 
made  in  time  to  prevent  them 

a)  Provide  easy  way  to  project  income  and  expenses 
over  the  fiscal  year  on  a month  by  month  basis 
so  as  to  provide  a ready  measure  of  actual  per- 
formance vs.  budget. 
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b)  Provide  way  to  flag  amounts  or  items  when  pre- 
determined tolerances  or  dates  are  exceeded 

13.  Provide  and  maintain  access  to  data: 

a)  Chart  of  Accounts 

b)  Future  budget  data  by  month  by  object  code 
within  account 

c)  Current  fiscal  year  budget  data  by  month  by 
object  code  within  account 

d)  Last  fiscal  year  budget  data  by  month  by  object 
code  within  account 

e)  Current  fiscal  year  actual  data  by  month  by 
object  code  within  account 

f)  Last  fiscal  year  actual  data  by  month  by  object 
code  within  account 

q)  Historical  data,  up  to  10  years  of  budget  and 
actual  data  by  object  summary  within  account 

h)  Salary  and  other  data  required  for  proposal 
preparation 

14.  Promote  optimal  use  of  fund  accounts  so  as  to  con- 
serve qeneral  monies 

a)  Provide  directory  (or  directories)  and  an 
application  index  of  funds  so  as  to  readily 
show  how  they  can  be  applied.  This  would 
require  collection  and  maintenance  of  abbrevi- 
ated text  of  fund  description  and  donor's 
intentions. 

b)  Enhance  existing  reports  (X52,  X53  and/or  X56) 
with  available  data  so  as  to  make  them  more 
useful  in  applying  funds. 

c)  Provide  for  production  of  a report  in  X52/X53 
format  showing  10  years  of  historical  data. 

d)  Explore  other  ways  to  promote  use  of  funds  when 
it  is  optional,  such  as  matching  fund  expendi- 
tures with  a certain  amount  of  General  money. 

15.  Support  monitoring  of  operating  budget 

a)  Budget  vs.  actual 


b)  'Operating  gap* 


16.  Support,  improve  or  replace  the  following  reports 
or  items  of  information: 


a)  Printed  Budget 


i) 

In  detail  by  account  within  departments 
and  areas  of  responsibility 

ii) 

In  'Schedule  A'  format  for  inclusion  in 
the  Treasurer's  Report 

iii) 

In  functional  format 

b)  Schedules  for  the  Treasurer's  Report 

c)  Indirect  Cost  Recovery  Percentage  based  on  CAO 
Studies 


d)  Analyze  effects  of  potential  'dollar  budgeting' 
decisions,  such  as  salary  change,  etc.  Be 
sure  to  provide  for  changing  scholarship,  fel- 
lowship and  stipend  rates  when  changing  tui- 
tion. 

e)  MITOP 

f)  Dynamic  Model 

i)  Provide  for  automatic  interrelationship 
so  that  when  data  changes  the  subseguent 
effects  are  shown 

ii)  Provide  for  ease  of  rerunning  with 
changes  in  variables  and  assumptions  to 
answer  'what  if'  guestions 

iii)  Explore  use  of  Boeing's  Executive  Infor- 
mation System  or  other  packages  to  sup- 
port modeling 

g)  Periodic  Summary  of  Operations 

h)  Budget  Authorizations  and  Changes,  and  explana- 
tions of  the  changes,  including  dollar  budget- 
ing. 

i)  Provisional  and  approved  Budget  Authori- 
zations 

ii)  Changes  in  authorized  amounts  or  alloca- 
tions and  explanations  of  same,  including 
dollar  budgeting 
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i)  Gross  and  net  effect  of  budget  changes,  includ- 
ing, but  identifying,  ‘dollar  budgeting* 

1)  Budqet  vs.  Actual  Reports  (X80,  X8J,  Xfl4) 

k)  Detailed  Transaction  Report 

i)  Print  account  title  on  DTR 

ii)  Include  detail  of  Purchase  Order  Commit- 
ments 

iii)  Provide  more  information  in  description 
and  reference  fields  so  as  to  facilitate 
trackinq  expenses 

iv)  Expand  data  content  to  include  YTD  and 
cumulative  data 

v)  Do  not  produce  DTR  in  months  when  there 
is  no  activity  for  an  account 

l)  Monthly  Statement 

i)  Consider  showing  'Travel  Outstanding' 
immediately  following  'Travel*  and  subto- 
taling them 

ii)  Supply  meaningful  Purchase  Order  Commit- 
ment data 

m)  List  of  accounts  about  to  expire 

n)  Budqet  proposal  forms  and  supporting  documents 

o)  Area  of  Responsibility  Report 

p)  Department  Profiles 

q)  Report  of  Fund  Crafts 

r)  Physical  Plant  Summaty 

17.  Supply  new  reports  as  required  for  fiscal  planning 

and  budgeting 

a)  Analysis  of  faculty  support,  in  both  E.F.T.  and 
dollars,  contributed  by  laboratories  to  aca- 
demic departments 

b)  Report  on  research  type,  discipline  and  func- 
tion so  as  to  satisfy  cotk  NS F and  MIT  re juj. fo- 
ments 
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c)  Monthly  Analysis 


i)  Determine  it"  Monthly  Analysis  should  be 
published  in  place  ot  or  in  addition  to 
Monthly  Statement 

ii)  Investigate  rounding  of  dollar  amounts  to 
nearest  $ 1 

iii)  Investigate  feasibility  of  not  publishing 
Monthly  Analysis  for  months  in  which 
there  is  no  activity  in  an  account 

iv)  Provide  for  including  or  excluding  cer- 
tain data  depending  on  user  requirements, 
i.e.  eliminate  billing  and  fiscal  year- 
to-date  data  from  report  to  principal 
investigator,  etc. 

v)  In  forms  design  try  to  show  subsections 
by  rounding  tops  of  column  heads 

vi)  Consider  showing  'Travel  Outstanding' 
immediately  following  'Travel',  and  sub- 
totaling them 

vii)  Print  account  numbers  in  lower  right  cor- 
ner for  easy  lookup  when  reports  are 
filed  in  a notebook 

viii)  Print  notes  to  show  special  restrictions. 
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ix)  Provide  for  flexibility  in  format  for 
content  (optional  columns) 

x)  Print  notes  that  describe  budget  changes 

xi)  Supply  meaningful  Purchase  Order  Commit- 

ment data 

d)  Summary  Analysis  for: 

i)  Parent  Accounts 

ii ) Departments  and  subdepartments 

iii)  Schools 

iv)  Areas  of  Responsibility 

v)  The  Institute 

vi)  Principal  investigator 
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vii)  Research  Type,  Discipline  and/or  function 

viii)  Other  subdivisions  as  required 


e)  Terminal  formats  for  entering  budget  proposals 

f)  Budget  Projection  - Month  by  month  projection 
by  object  codes  for  one  or  a group  of  accounts. 

g)  Additional  reports  used  by  certain  departments, 
such  as  K.  Keays  series 

18.  On  Personnel  Action  Form  add  a box  to  indicate 
whether  person  hired  is  a replacement  or  an  addi- 
tion. 

19.  Support  Special  reports  for  budget-related  activi- 
ties 

a)  Standard  reports  at  non-standard  times 

b)  Standard  reports  for  non-standard  periods 

i)  Contract  period 

ii)  Sponsor’s  fiscal  year 

c)  Standard  data  in  non-standard  formats 

d)  Report-writer  language  for  fully  customized 
reports.  This  language  must  be  easily  learned 
and  used. 

20.  Support  for  on-line  operations  with  budget  data- 
base 

a)  'Menu*  tor  standard  inquiry  series 

b)  Inquiry  language  for  special  use 

c)  Support  for  on-line  requests  for  reports  to  be 
printed  either  on  terminal  or  at  remote  printer 

21.  Provide  data  security  and  recoverability 

a)  Protect  sensitive  data  against  unauthorized  use 
by  checking  and  logging  indentity  of  user  and, 
possibly,  by  encoding  data 

b)  Prevent  data  from  being  changed  by  unauthorized 
persons,  access  would  be  'read  only’  except  to 


c)  System  must  provide  data  integrity  through  log- 
ging of  chanqes  and  capability  of  reversing 
them 

d)  Provide  adequate  file  backup  procedures 

22.  Provide  a simplified  proposal  preparation  proce- 
dure that  will  support  both  on-line  and  manual 
preparation  of  budgets. 

23.  Investigate  proposal  preparation  using  primarily 
summary  object  codes. 

a)  Standard  MIT  monthly  statement  summary  object 
codes  for  subtotals 

b)  Billing  summary  object  codes 

24.  Provide  for  review  of  budget  proposals  and  changes 
by  the  Budget  Office  in  simplified  ways 

a)  Investigate  feasitility  of  manually-prepared 
machine-readable  budget  proposal  worksheets 

b)  Provide  for  review  and  acceptance  of  proposals 
prepared  either  manually  or  on-line 

c)  Provide  maximum  effective  amount  of  computer 
editing  of  budget  proposals 

d)  Provide  check  to  be  sure  proposals  are  within 
target  amount 

e)  Compare  actual  E.F.T.  and  head  count  against 
allowances 

f)  Provide  check  to  be  sure  every  open  account  has 
a proposal 

g)  Be  able  to  tell  status  of  every  proposal 

25.  Identify  'base  qeneral'  in  budget 

26.  Provide  for  changing  Employee  Benefit  amounts  when 
changes  are  made  affecting  the  amount  of  Salary 
and  tfages  budgeted 

27.  Encourage  the  use  of  program  budgeting  while  still 
supporting  other  effective  budgeting  techniques 
currently  in  use 

28.  Provide  logical  integrity  of  budget  data  by 
assigning  ownership  and  responsibility  for  each 
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data  element.  Administrators  should  be  able  to 
chanqe  certain  elements  or  allocations  on  their 
own  authority,  whereas  others  should  require 
Budget.  Or t ice  approval 

29.  Provide  a system  for  tracking  research  proposals 
so  as  to  show  whether  they  arc  accepted  or 
rejected,  what  amount  of  funding  is  made  availa- 
ble, funding  aqency,  principal  investigator, 
lenqt h of  contract,  special  restrictions,  and 
other  appropriate  information.  Record  GSP  propo- 
sal number  on  C0 1 form. 

30.  Support  the  establishment  and  use  of  a system  of 
Discipline/Function  codes  for  research  projects 

31.  Eliminate  the  need  for  certain  departmentallv-pro- 
duced  reports  by  making  available  cither  standard 
or  special  reports. 

32.  Promote  simplification  of  the  budgeting  and  finan- 
cial planning  operations 

33.  Provide  documentation  and  audit  trail  required  for 
follow-up  of  discrepancies  in  system,  operational 
or  user  areas. 

3h.  Support  handling  of  all  required  aspects  of  spe- 
cial items  such  as: 

a)  Nonrecurring  equipment 

b)  Carryforward  amounts 

c)  Sabbatical  leaves 

d)  Crafts 

e)  Reserves 

f)  Other  special  requests 

35.  Support  Fund  Drafts  by  computer  via  on-line  and 
batch  as  well  as  manual  (log  sheet)  requests  from 
user  departments.  Use  on-line  checking  by  Budget 
Office  where  feasible. 

36.  Provide  for  recording  joint  or  non-standard  sup- 
port for  an  account 

37.  Determine  desirability  and  feasibility  of  encum- 
bering salary  and  wage  budgeted  amounts. 
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38.  Establish  data  base  to  support,  budget  activities 
as  veil  as  AKS  and  other  data  or  systems 

39.  Investigate  the  feasibility  of  updating  actual 
income  and  expense  data  more  frequently  than  once 
a month. 

40.  Review  system  of  fund  purpose  codes  to  see  if  they 
could  be  made  more  beneficial  to  both  gift  system 
and  fund  users. 

41.  Provide  for  communication  between  Budget  System 
and  Gift  System. 

42.  Provide  for  additional  data  and  types  of  data  to 
be  stored  as  requirements  occur 

a)  Provide  for  an  open-ended  system  of  descriptors 
for  accounts  or  objects  within  an  account  to 
carry  whatever  supplementary  data  may  bo  needed 
by  users.  This  would  include; 

i)  Data  on  special  funding  and  non-recurring 
expenses 

ii)  Indicators  as  to  Functional  Summary  cate- 
gories 

iii)  Complete  sot  of  applicable  Donor  Purpose 
codes  for  fund  accounts 

b)  Provide  for  access  to  data  via  the  special  des- 
criptors 

43.  Provide  for  discussion  of  all  projected  changes 
with  affected  users  whenever  feasible 

44.  Provide  formal  training  for  users  when  system  is 
introduced  and  periodically  thereafter 

45.  Provide,  maintain  and  distribute  adequate  documen- 
tation for  all  system  users. 

46.  Support  various  Employee  Benefit.  Codes  and  Over- 
head Rocovery  Rates  as  appropriate 

a)  Ensure  that  data  is  available  to  show  employee 
benefit  and  overhead  recovery  rates  appropriate 
to  the  accounting  period. 

b)  Support  indlvidusl  employee  benefit  rates  to 
accommodate  personnel  from  other  universities 
who  work  on  projects  at  h • L • T • « such  as  the 
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consortium  for  the  Center  for  Materials 
Research  in  Archaeology  and  Technology 

47.  Speed  up  delivery  of  reports  to  users 

48.  Explore  possibility  of  accounting  cutoff  at  the 

. end  of  the  month 
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Appendix . C 


PINAL  DU  DOTTING  SYSTEM  FUNCTIONAL  l>  L^U  IhliS  ENTS  AS  USED  IN 

THE  SON  ANALYSIS. 


1.  Fund  accounts  will  be  categorized  by  fund  pur- 
poses. 

2.  Fund  accounts  can  be  categorized  by  principal 
type. 

3.  Fund  accounts  can  be  categorized  by  income  type. 

COMMENT: 

Principal  types  may  include  endowment,  quasi-en- 
dowment, and  term  endowment. 

Income  types  may  include:  Unrestricted,  Res- 
tricted, Designated,  or  Restricted  and  Further 
Designated . 

4.  Each  fund  account  will  be  described  via  abbrevi- 
ated text  description. 

COMMENT: 

The  current  60-character  fields  may  be  used  for 
this  purpose. 

5.  Short-term  and  long-term  planning  data  will  be 
provided  by  Senior  Managers. 

COMMENT: 

Senior  Manaqers  are:  Deans,  Department  Heads, 

Lab  Directors,  and  Vice  Presidents. 

6.  Planning  data  will  be  provided  in  a standardized 
format. 

COMMENT: 

Department  profile  format. 
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7.  Data  regardin']  special  financial  arrangements  made 
by  managers  will  be  maintained. 

COMMENT : 

Could  be  between  managers  or  between  fund  donors 
and  managers. 

8.  Personnel  budgets  can  be  developed  in  dollars. 

COMMENT: 

Either  average  or  actual  figures. 

9.  Personnel  budgets  can  be  developed  in  EPT. 

10.  There  will  be  a facility  for  converting 
salary/wage  information  between  dollars  and  EFT. 

COMMENT: 

This  conversion  should  be  as  automatic  as  possi- 
ble . 

11.  Certain  objects  may  be  logically  related  to  grouis 
of  other  objects. 

COMMENT: 

For  example,  summary  object  codes. 

12.  A particular  object  may  belong  to  multiple  object 
qroups. 

COMMENT: 

For  example,  certain  codes  may  be  reserved  as 
summary  codes  tor  specific  groups  of  other 
object  codes.  Summary  codes  might  include  subto- 
tal information. 

13.  Manpower  can  be  reported  in  alternative  units. 

COMMENT: 

For  instance,  dollars,  man-days,  man-months, 
man-years. 

14.  There  will  be  special  object  codes  available  for 
use  by  each  department. 

COMMENT: 
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Each  department  would  determine  its  own 
categorizations. 

Instance:  additional  subdivisions  on  travel: 
Travel  to  LA,  Travel  to  Washington,  etc. 

15.  Reports  will  be  physically  easy  to  handle. 

COMMENT: 

3800  printer  would  help  to  do  this  by  increasing 
data  capacity  per  page. 

16.  Budgeting  and  plarminq  data  can  be  accessed  read- 
ily by  other  systems. 

17.  The  budqet  system  can  access  directly  data  in 
other  systems'  files. 

COMMENT: 

Including  ARS,  Payroll,  Gift  systems. 

18.  There  will  be  a general  comparison  reporting  capa- 
bility. 

COMMENT: 

Hay  be  budget-ver sus-budget  or  budget- versus- ac- 
tual. 

May  be  for  diiferent  time  periods  (e.g.,  a par- 
ticular week  this  year  versus  same  week  last 
lear) . 

Other  examples  would  be:  one  department  versus 
rest  of  school;  comparisons  between  budgets  of 
different  principal  investigators. 

19.  Items  exceeding  prespecified  bounds  can  be  high- 
lighted. 

20.  Chart  of  Accounts  arid  associated  supplementary 
data  will  be  accessable  by  Budget  System, 

21.  Current  fiscal  year  budget,  data  will  be  main- 
tained. 

22.  Future  Budget  data  will  be  maintained. 

23.  Last  fiscal  year  Budget  data  will  be  maintained. 


106 


24.  Current  fiscal  year  Actual  data  will  be  main- 
tained. 

25.  Last  fiscal  year  Actual  data  will  be  maintained. 

COMMENT: 

in  general,  income  and  expense  data  will  be 
accessable  by  month  and  object  code  within 
account . 

2b.  Historical  Budget  data  will  be  maintained  for  up 
to  10  years. 

COMMENT: 

May  be  aggregated;  will  be  off-line. 

27.  Historical  Actual  data  will  be  maintained  for  up 
to  10  years. 

COMMENT: 

May  be  aggregated;  will  be  off-line. 

28.  Data  required  for  budget  proposal  preparation  and 
not  available  elsewhere  will  be  maintained. 

COMMENT: 

e.q.,  salary  data  from  payroll  system;  target 
data. 

29.  Budqetcd  income  and  expense  data  will  be  prorated 
automatically  on  a inonth-by-month  basis. 

COMMENT: 

Prorations  can  be  selected  from  standard  pro- 
files. 

Special  proration  profiles  may  be  supplied  by 
managers. 

There  will  also  be  a "no  proration"  alternative. 

30.  Information  to  facilitate  the  effective  use  of 
fund  accounts  will  be  available. 

COMMENT: 

Provide  directory  (or  directories)  and  an  appli- 
cation index  of  tunds  so  as  to  readily  show  how 
they  can  be  applied.  This  would  require 
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collection  and  maintenance  or  abbreviated  text 
of  donor's  intentions  and  fund  description. 
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Enhance  existing  reports  (X52,  X*»3  and/or  XSt» ) 
with  available  data  so  as  to  make  them  more  use- 
ful  in  applyinq  funds, 

Provide  for  production  of  a report  in  X52/X53 
format  showing  5 years  of  historical  data. 

Explore  other  ways  to  promote  use  of  funds  when 
it  is  optional,  such  as  matching  fund  expendi- 
tures with  a certain  amount  of  General  money. 

31.  Honitorinq  of  the  operating  budget  will  be  sup- 
ported. 

CONSENT: 

e.q.,  budget- versus-actual  reports;  operating 
qap  analysis. 

32.  Various  Future  Budget  reports  will  be  generated. 

CONSENT: 

Support,  improve,  or  replace  the  following 
reports: 

Printed  budget: 

In  detail  by  account  within  departments  and 
areas  ot  responsibility. 

In  'Schedule  A'  format  for  inclusion  in 
Treasurer's  report. 

In  functional  format. 

Physical  plant  summary. 

Department  profiles. 

Budget  Authorizations  and  Changes,  and  explana- 
tions of  the  changes,  including  dollar  budget- 
ing. 

Provisional  and  approved  Budget  Authoriza- 
tions. 

Changes  in  authorized  amounts  or  alloca- 
tions and  explanations  of  sane,  including 
dollar  budgeting. 
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Gross  and  net  effect  of  budget  changes, 
including,  but  identifying,  'dollar  budgeting'. 

Budget  proposal  forms  and  supporting  documents. 

33.  Periodic  operating  reports  for  each  account  will 
be  generated. 

COMMENT: 

Reports  will  include  current  budget  and  current 
actual-to-date  data. 

Modified  detailed  transaction  report  (ARS) . 

Print  account  title  on  DTR. 

Include  detail  of  Purchase  Order  Commit- 
ments. 

Provide  additional  information  in  descrip- 
tion and  reference  fields  so  as  to  facili- 
tate tracking  of  expenses. 

Expand  data  content  so  as  to  include  YTD 
and  cumulative  data. 

i 

Do  not  produce  DTR  in  months  when  there  is 
no  activity  on  account. 

Monthly  statement  or  its  replacement  (monthly 
analysis) . 

Consider  showing  'travel  outstanding' 
immediately  after  'travel,'  and  subtotaling 
them. 

Supply  meaningful  purchase  order  commitment 
data. 

Budget  versus  Actual  reports  (X80,  X83, 

X84)  . 

34.  Various  special-purpose  (non-periodic)  reports 
will  be  generated. 

COMMENT: 

Schedules  for  Treasurer's  Report. 

Indirect  cost  recovery  percentage,  based  on  CAC 
studies. 

MITOP. 
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Periodic  Summary  of  Operations. 
List  of  accounts  about  to  expire 


35.  Tho  data  necessary  for  use  by  tue  Dynamic  Model 
will  be  generated. 

COMMENT: 

The  model  will  support  automatic  interrelation- 
ships of  variables. 

36.  Ad  hoc  requests  for  information  will  be  supported. 

COMMENT: 

For  example,  analyzing  the  effects  of  potential 
’dollar  budgeting*  decisions,  such  as  1 percent 
salary  changes,  etc. 

37.  Various  funds  reports  will  be  generated. 

COMMENT: 

In  particular,  the  report  on  Funds  drafts. 

Also  Funds  Schedule  for  Treasurer's  Report. 

3U.  The  system  will  have  access  to  certain  personnel 
hiring  data. 

COMMENT: 

Monitoring  head  count  allowances. 

Add  box  on  Personnel  Action  form  to  indicate 
whether  person  hired  is  a replacement  or  an 
addition. 

39.  Certain  budget  report  data  items  can  be  optionally 
included  or  excluded  from  Monthly  Analysis  Report 
as  specified  by  the  user. 

COMMENT: 

e.q. , eliminate  billing  and  fiscal  YTD  data  from 
report  to  principal  investigator. 

40.  Variations  of  standard  Budget  System  reports  will 
be  developed  as  requested. 

COMMENT: 
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Analysis  of  faculty  support,  in  both  F.F.T.  and 
dollars,  contributed  by  laboratories  to  academic 
departments. 


heport  on  research  type,  discipline  and  function 
so  as  to  satisfy  both  NSF  and  MIT  requirements. 

41.  New  budget  reports  will  be  developed  as  required. 

COMMENT: 

e.g..  Monthly  Analysis: 

Determine  if  Monthly  Analysis  should  be 
published  in  place  of  or  in  addition  to 
Monthly  Statement. 

Investigate  rounding  of  dollar  amounts  to 
nearest  $1. 

Investigate  feasibility  of  not  publishing 
Monthly  Analysis  for  months  in  which  there 
is  no  activity  in  an  account. 

Provide  for  including  or  excluding  certain 
data  depending  on  user  requirements,  i.e, 
eliminate  billing  and  fiscal  year-to-date 
data  from  report  to  principal  investigator, 
etc. 

In  forms  design  try  to  show  subsections  by 
rounding  tops  of  column  heads. 

Consider  showing  'Travel  Outstanding' 
immediately  following  'Travel',  and  subto- 
talinq  them. 

Print  account  numbers  in  lower  rijht  corner 
for  easy  lookup  when  reports  are  filed  in  a 
notebook. 

Print  notes  to  show  special  restrictions. 

Provide  for  flexibility  in  format  for  con- 
tent (optional  columns) . 

Print  notes  that  describe  budget  changes. 

Supply  meaningful  Purchase  Order  Commitment 
data. 

42.  There  will  be  a simple  report -vr it  ing  facility. 
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43.  Users  can  develop  their  own  special  reports  using 
the  report  writing  facility. 

44.  There  will  he  an  on-line  ironu -or iented  query 
facility. 

45.  There  will  be  an  on-line  ad  hoc  query  facility. 

46.  Reports  generated  on-line  can  be  directed  to  the 
system  printer  or  to  users'  printer/terminal. 

47.  Identity  and  activity  of  users  will  be  logged. 

COMMENT: 

Should  be  provided  by  DBMS. 

48.  Data  items  can  be  accessed  only  by  permissable 
users. 

49.  Data  items  can  be  changed  only  by  their  owner. 

50.  There  will  be  a set  of  permissable  users  for  each 
data  item. 

51.  Each  data  item  will  have  a unique  owner. 

52.  Data  items  can  be  encoded  for  security. 

53.  There  will  be  a log  of  all  database  changes. 

54.  There  will  be  a file  backup  facility. 

55.  The  database's  integrity  can  be  restored  using 
backup  files  and  change  log  if  necessary. 

56.  Budget  proposals  can  be  prepared  manually. 

57.  Budget  proposals  can  be  prepared  on-line. 


58.  Budget  proposals  will  be  automatically  checked  and 
edited  to  the  extent  possible. 

COMMENT : 

Every  open  account  must  have  an  associated  pro- 
posal. 

EFT  cannot  exceed  100  percent  pet  person. 

59.  There  will  be  controlling  limits  on  amounts  in 
proposed  budgets  and  budget  changes. 


COMMENT: 
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Check  that  proposals  arc  within  target  amount, 
or  within  sponsor’s  limit. 

Compare  actual  EFT  and  head  count  against  allo- 
wances. 

Bay  be  desirable  to  have  coj.  rols  on  summaries 
also. 

60.  Budget  proposals  will  be  reviewed  by  the  budget 
office  and/or  OSP. 

61.  Budqet  changes  will  be  reviewed  by  the  budget  off- 
ice and/or  OSP. 

62.  Sources  of  funding  for  each  account  will  be  iden- 
tified. 

COMMENT: 

Identification  information  may  be  included  in 
budget  account  record, 

63.  Budqeted  employee  benefits  will  be  changed  auto- 
matically following  changes  in  budgeted  salary  and 
waqe  amounts  or  Ed  rates. 

64.  All  currently  used  budgeting  techniques  will  be 
supported . 

COMMENT: 

Including  line  item  budgeting,  program  budget- 
ing, and  task-oriented  budgeting. 

System  should  promote  program  budgeting. 

65.  Research  proposal  information  can  be  stored, 
updated,  and  accessed. 

COMMENT: 

Provide  various  kinds  of  information  for  track- 
ing research  proposals  to  show  whether  they  are 
accepted  or  rejected,  what  amount  of  funding  is 
requested  and  made  available,  funding  agency, 
principal  investigator,  length  of  contract,  spe- 
cial restrictions,  and  other  appropriate  infor- 
mation. Record  CSP  proposal  number  on  001  form. 

66.  Research  accounts  and  proposals  will  be  categor- 
ized by  typo,  discipline,  and  function. 
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67.  There  will  be  documented  audit  trails  for  deter- 
mining system  discrepancies. 

68.  Required  aspects  of  non-recurring  expenses  will  be 
supported. 

COMMENT: 

Concerns  primarily  sabbatical  leaves,  drafts, 
carryforward  amounts,  and  nonrecurring  equip- 
ment . 

69.  Fund  drafts  can  be  performed  on-line. 

70.  Fund  drafts  can  be  performed  in  batch  mode. 

71.  Fund  drafts  can  be  checked  and  approved  on-line  by 
Budget  Office. 

COMMENT: 

Check  may  be  done  by  Budget  Office,  or  the  res- 
ponsible officer. 

72.  Additional  data  item  types  can  be  added  to 
accounts  or  objects  within  accounts. 

73.  New  data  items  can  include  or  refer  to  supplemen- 
tary data  needed  by  users. 

74.  Formal  training  in  the  use  of  the  system  will  be 
provided  to  users. 

COMMENT: 

Training  and  use  documentation  will  be  made 
available  to  legitimate  system  users. 

75.  Non-standard  employee  benefit  calculations  will  be 
supported. 

COMMENT: 

Support  individual  employee  benefit  rates  to 
accommodate  personnel  from  other  universities 
who  work  on  projects  at  MIT  (e.g..  Consortium 
for  Materials  Eesearch  in  Archealogy  and  Tech- 
nology) . 

76.  Overhead  recovery  rate  calculations  will  be  sup- 
ported. 
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77.  Standard  p ...  . odic  report  s will  be  produced  and 
distributed  to  users  .uickly  as  possible. 

COMMENT: 

Minimize  time  between  cutoff  date  and  report 
receipt. 

3800  printer  will  help  by  shortening  printout 
time  and  by  printing  in  distribution  sequence. 


* 


I 
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Appendix . D 

FORM  USED  IN  GATHERING  I NTLfc DLP LNDENCY  DATA 


The  data  form  shown  on  the  following  page  was  used  for 
gathering  the  interdependency  data  during  the  interdepen- 
dency analysis  phase  of  the  study. 


Appendix  E 

BUDGETING  SYSTEM  REFINEMENT  INTERDEPENDENCIES 


PR 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

2 


TO 

4 

17 

20 

30 

36 

37 

58 

60 

71 

72 
4 


WT  DESCRIPTION 

S Text  description  will  reinforce  and 
describe  the  categorization. 

A Fund  purpose  data  may  be  stored  elsewhere. 

A Fund  purpose  data  may  also  be  in  Chart  of 
Accounts. 

S Fund  purpose  code  is  a important  instance 
of  "effective-use"  information. 

W Possible  "fund  purpose"  report. 

W Possibly  want  to  include  fund  purpose 
information . 

A Check  budget  proposals  regarding  fund 
purpose. 

A Reviewer  would  check  fund  purpose  for 
consistency. 

N Can  be  checked  for  consistency. 

S May  want  to  add  new  purposes. 

S Text  description  will  reinforce  and 
describe  the  categorization. 
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2 17  H 

2 20  A 

2 30  S 

2 36  V 

2 37  A 

3 4 S 

3 7 A 

3 17  W 

3 19  A 

3 20  A 

3 30  S 

3 36  A 

3 37  S 

4 17  A 

4 30  S 

4 36  W 

4 37  S 

5 6 S 


Fund  purpose  data  may  be  stored  elsewhere. 

Chart  of  Accounts  contains  fund  accounts. 

Principal  type  is  critical  effective  use 
information. 

Possible  fund  report. 

Information  to  be  included  in  fund  reports. 

Text  description  will  describe  and 
reinforce  categorization. 

Often  have  special  income  restrictions. 

Gift  system  is  source  for  fund  account 
data. 

Accumulated  income  important  to  monitor. 

Carried  in  Chart  of  Accounts. 

Income  type  important  regarding  how  spent. 

Likely  fund  report. 

Possibly  want  to  include  fund  purpose 
information  here. 

Other  systems  may  need  to  access  descrip- 
tion data. 

Fund  purpose  description  used  in  directory 
entry. 

Text  description  likely  target  of  ad  hoc 
requests. 

Text  description  would  be  included  in  many 
reports. 

Use  and  capture  of  planning  data  related  to 
format. 


i 
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5 

5 

5 

6 
6 

6 

7 

7 

7 

7 

7 

7 

7 

7 

8 
8 
8 

8 

a 

8 


22  S Belated  information  sources. 

34  A Might  want  to  develop  projection  reports. 

35  S Major  purpose  of  planning  data  is  to 

provide  DM  input. 

22  W Common  formatting  issue. 

34  H Summary  planning  reports  possibly  contin- 

gent on  planning  data  format. 

35  A Format  affects  what  can  be  reguested. 

30  A Special  arrangements  tor  funds. 

37  U May  want  to  report  information  regarding 
special  arrangements. 

58  A Hay  be  ahle  to  automate  checking  to  include 

SFA. 

59  A Hay  be  limits  or  controls  on  SFAs. 

60  W SFAs  are  grounds  for  examination. 

62  S Routine  examinations. 

68  S An  SFA  is  a special  item  of  importance. 

71  W SFAs  would  need  to  be  checked. 

10  S Common  conversion  issue. 

13  A Common  conversion  issues, 

29  A Proration  ot  personnel  expenses  important 
issue. 

63  S Employee  benefits  developed  from  personnel 

budqets  in  dollars. 

75  S Employee  benefit  calculations  need  personnel 

information  in  dollars. 

10  S Common  conversion  issue. 
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9 

9 

9 

9 

9 

10 

10 

10 

1 1 
1 1 
11 
1 1 

12 

12 

15 

16 

16 

16 

17 


13  S EFT  required  for  certain  reporting  units. 

29  A Proration  of  personnel  expenses  important 
issue  here. 

33  A Standard  reports  include  manpower. 

38  W Need  EFT  to  properly  monitor  headcounts. 

59  M One  control  item. 

13  S Common  conversion  issues. 

28  A Budget  proposal  data  may  need  conversion 
facilities . 

38  N Hay  need  conversion  facilities  to  make 
effective  use. 

12  S Common  logical  relationships  issue. 

14  A Special  codes  have  to  summarize  correctly. 

34  A Logical  relationships  used  in  summarizing. 

35  A Model  uses  mostly  summary  data,  and  logical 

relationships  define  certain  summar izations. 
14  A Department  summary  codes  need  logical 
groupings. 

34  S Summar izations  defined  in  logical  groupings. 

77  S Common  preparation  issue  - easier  handling 
makes  for  faster  delivery. 

48  A Allowable  accesses  must  be  controlled  for 

other  systems  as  well  as  individuals. 

49  A Need  change  protection  as  regards  other 

systems. 

52  W Other  systems  may  need  encription  key  access. 
20  S budget  system  will  need  access  to  chart  data. 


17 

69 

W 

Need 

link 

to 

Funds  system. 

17 

71 

H 

Need 

Funds  system  link. 

Id 

19 

S 

Comparisons 

indicate  items  to 

be  highlighted 

18 

22 

A 

Data 

used 

in 

compar isons. 

18 

23 

A 

Data 

used 

in 

comparisons. 

18 

24 

A 

Data 

used 

in 

comparisons. 

18 

25 

A 

Data 

used 

in 

compar isons. 

18 

26 

W 

Data 

used 

in 

compar isons. 

18 

27 

w 

Data 

used 

in 

comparisons. 

18 

29 

s 

Prorating 

generates  detailed 

information  for 

doing  comparisons . 


18 

31 

A 

Comparisons  necessary  for  monitoring. 

18 

32 

A 

Comparisons  included  in  budget  reports. 

18 

33 

A 

Comparisons  included  in  periodic  analysis 

reports. 

18 

34 

A 

Some  comparisons  included  in  summary  reports 

18 

39 

A 

Nay  include  comparisons . 

18 

41 

A 

Nay  include  comparisons. 

20 

22 

A 

Related  data  maintainance  issue. 

20 

23 

A 

Related  data  maintainance  issue. 

20 

24 

A 

Related  data  maintainance  issue. 

20 

25 

A 

Related  data  maintainance  issue. 

20 

31 

A 

Data  used  in  monitoring. 

20 

32 

A 

Data  is  source  for  reports. 

20 

33 

A 

Data  is  source  for  reports. 

20 

34 

A 

Data  is  source  for  reports. 

20 

35 

A 

Data  is  source  for  reports. 
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36  A 

37  W 
41  A 
56  A 
62  U 


20  66  H 

20  68  W 


20  72  A 


20  73  V 

21  23  H 

21  29  S 

21  30  S 

21  31  S 

21  32  S 

21  33  A 

21  35  W 

21  38  A 

21  39  A 

21  40  S 

21  60  A 


21  62  A 

22  29  A 


Data  is  source  for  reports. 

Data  possibly  source  tor  reports. 

Data  possibly  source  tor  reports. 

Chart  data  used  in  checking. 

Type  of  supplementary  data. 

Type  of  supplementary  data. 

Requires  certain  supplementary  Chart  data. 
Descriptors  tray  need  t o be  used  for 
supplementary  Chart  data. 

Descriptors  tray  need  to  refer  to 
supplementary  Chart  data. 

Would  need  to  transfer  data  at  year  end. 
Requires  current  budget  data. 

Used  in  monitoring  reports. 

Used  in  monitoring  reports. 

Used  in  monitoring  reports. 

Used  in  monitoring  reports. 

Portions  of  data  may  be  used  as  input  to  DM. 
Need  budget  data  to  do  function. 

Choices  may  include  CFY  budget  data. 
Variations  may  require  certain  CFY  budget 

data. 

Proposed  revirc  often  requires  examination 

of  CFY  budget  data.  ' ' \ 

1 

Part  of  CFY  budget  data. 

Future  budget  data  submitted  in  prorated 
form  subject,  to  change. 
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22 

32 

S 

Data  needed  for  reports. 

22 

35 

A 

Data  needed  by  DM. 

22 

36 

A 

Requests  for  future  budget  data. 

22 

41 

A 

Hay  require  future  budget  data. 

22 

6C 

A 

Review  of  data  maintained. 

22 

61 

A 

Review  ot  data  maintained. 

22 

62 

W 

S of  F data  must  be  maintained  with  future 

budget  data. 

22 

63 

A 

Automatic  changes  will  be  applied  to  future 

budqet  data. 

22 

65 

A 

Commonality  in  how  to  treat  data. 

23 

36 

A 

Needed  for  requests. 

24 

31 

A 

Needed  tor  monitoring  operating  budget. 

24 

33 

A 

Source  data  for  reports. 

24 

34 

A 

Source  data  for  reports. 

24 

36 

S 

Heavily  used  data  for  ad  hoc  requests  of 

informat  ion. 

24 

39 

A 

Optional  data  items  must  be  available  or 

derivable. 

24 

40 

A 

Required  data  for  variations  may  include 

current  acut.al  data. 

24 

41 

A 

May  include  current  year  actual  data. 

24 

58 

A 

Needed  for  editing  and  checking  of  future 

budgets. 

25 

30 

H 

Actual  data  needed  for  funds  application. 

25 

31 

W 

Needed  for  comparison  to  last  year. 

25 

32 

A 

LFY  Actual  data  as  potential  data  source. 
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25  33  A LFY  Actual  data  is  potential  data  source. 

25  34  A LFY  Actual  data  is  potential  data  source. 

25  35  A LFY  Actual  data  is  potential  data  source. 

25  36  A LFY  Actual  data  is  potential  data  source. 

25  39  A LFY  Actual  data  is  potential  data  source. 

25  40  K LFY  ActuaL  data  is  potential  data  source. 

25  41  A LFY  Actual  data  is  potential  data  source. 

26  36  H Ad  hoc  requests  may  need  old  budget  data. 

27  36  W Ad  hoc  requests  may  need  old  budget  data. 

27  53  A DM  may  need  actual  data  for 

ex trap cl at  ion/modelling. 

28  38  A Hiring  data  not  now  maintained. 

28  56  W Manual  preparation  may  maxe  use  of  some  data. 

28  57  S On-line  preparation  will  need  data, 

28  58  A Certain  preparation  data  needed  for 

chec A inq /editing . 

28  59  H Preparer  might  need  to  interact  with  limits 

information. 

28  60  A May  need  special  data  for  review. 

28  61  A Hay  need  data  for  changes  review. 

29  30  S Effective  use  of  fund  accounts  depends  on 

accurately  prorated  data. 

29  31  A Prorated  data  important  for  operations 

monitoring. 

29  32  A Prorating  used  in  F8  report  generation. 

29  40  H Variation  may  involve  modification  to 
proration  arrangements. 


29  49 

29  56 

29  57 

29  63 

30  36 

30  37 

30  62 

30  69 

30  70 

30  71 

31  32 

31  33 

31  34 

31  36 

31  41 

31  61 

31  68 

32  33 

32  34 

32  37 


W Changing  proration  may  be  done  directly  by 
managers  via  on-line  access, 

A Budget  prorated  when  proration  established. 

A Budget  prorated  when  proration  established. 

A Automatic  change  to  proration  also. 

A Ad  hoc  requests  for  information  regarding 
fund  accounts  important. 

S Fund  reports  should  be  addressed  toward 
effective  use. 

W Easy  availability  of  S of  F information 
should  improve  et fectiveness  of  use. 

A Bakes  for  more  effective  use. 

W Drafts  related  to  effectiveness  of  use. 

A Fund  draft  checking  can  intercept 
ineffective  use. 

S Periodic  budget- versus-actual  reports  serve 
monitoring  needs. 

A Periodic  reports  may  serve  monitoring 
capability . 

A Summary  monitoring  reports. 

W Ad  hoc  monitoring. 

W Hay  need  to  develop  new  monitoring  reports. 

A Changes  impact  monitoring  function. 

W Special  items  may  need  special  monitoring. 

W Common  reporting  issues. 

W Common  reporting  issues. 

W Common  reporting  issues. 
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32  40 

32  41 

32  61 

32  64 

33  34 

33  36 

33  37 

33  39 

33  40 

33  41 

33  62 

34  36 

34  41 

34  42 

36  41 

36  42 

36  43 

36  45 

36  48 

36  72 


A Related  reporting  issue. 

A Related  reporting  issues. 

W Changes  may  be  reviewed  via  reports. 

W Needed  for  certain  report  requirements. 

A Common  data  source. 

A Common  data  for  typical  queries  and  reports. 

W Common  data  source. 

S Common  report  modification  issue. 

A Common  data  and  reports. 

S Monthly  analysis  scheme  common. 

W Sources  of  funding  information  may  be  in 
some  reports. 

S May  produce  special-purpose  report  using  ad 
hoc  facility. 

W May  develop  new  budget  reports  out  of 
special-purpose  reports. 

A May  produce  some  special  reports  using 
report  writer. 

W Ad  hoc  requirements  may  lead  to  new  reports. 

S Most  ad  hoc  requirements  accommodated  via 
report  writer. 

A Users  may  wish  to  develop  their  own  reports. 

A May  use  query  facility  to  answer  ad  hoc 
questions . 

S Data  control  makes  ad  hoc  query  use  more 
difficult . 

A New  data  item  types  make  ad  hoc  requirements 
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37  62  A 

39  40  A 

39  41  W 

39  72  W 

40  41  A 

40  65  H 

41  65  A 

4 1 72  A 

42  43  S 

42  46  H 

4 3 46  A 

43  47  V 

43  48  W 

43  74  S 

44  46  W 

44  47  A 

44  48  A 

44  60  A 


easier  to  implement. 

Funding  sources  will  be  shown  in  funds 
report . 

May  want  general  mechanisms  for  modification. 

Modifications  may  lead  to  new  reports. 

New  data  item  types  can  carry  data  regarding 
report  content. 

Variations  may  lead  to  new  reports. 

Budget  report  format  may  be  used  for 
research  proposal  reports. 

Research  proposal  information  prime 
candidates  for  new  reporting. 

Common  data  organization  issue. 

Facility  intended  for  users. 

Destination  code  in  reports. 

Report  directing  aids  must  be  available  to 
all  users  and  easy  to  use. 

Need  to  log  id  information  regarding  report 
writer  users. 

Constrains  use  of  report  writer. 

Train  use  of  report  writer  - make  it  easy  to 
use  and  le$rn. 

Possibly  need  to  dump  menu-query  output  to 
terminals. 

Log  query  users. 

Control  query  access. 

Proposal  review  could  use  query  facility. 
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44  61  A 

44  71  A 

44  74  A 

45  46  W 

45  47  A 

45  48  A 

45  74  A 

46  77  W 

47  48  A 

47  49  A 

47  53  A 

48  49  A 

48  50  S 

48  52  A 

49  51  S 

49  52  W 

49  53  W 

50  51  W 

53  55  S 

53  61  A 

53  63  W 

53  67  S 


Proposal  review  could  use  query  facility. 

Use  query  facility  for  funds  drafts. 

User  traininq  Mould  be  necessary. 

Nay  need  to  send  ad  hoc  results  to  users 
terminals. 

Log  query  users. 

Control  query  access. 

Need  user  training. 

Can  achieve  faster  distributino  via  remote 
printing  of  reports. 

Need  identity  to  determine  permissable  users. 
Need  identity  to  determine  owner. 

Activity  logging  would  include  database 
changes. 

Common  access  control  issue. 

Common  access  control. 

Encoding  can  be  used  to  insure  that  only 
permissable  users  get  access. 

Need  owner  id  concept  to  implement  control. 
Encoding  can  be  used  to  insure  that  only 
permissable  users  can  change  items. 

Validity  of  change  attumpts  logged. 

Common  access  issue. 

Need  log  to  restore. 

Can  locate  changes  via  log  stream. 

Need  to  log  automatic  changes  to  EOs. 

Log  is  important  part  of  audit  trail. 
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53 

72 

A 

Need  to  log  additions  of  new  data  elements. 

54 

55 

S 

Restore  via  backup. 

54 

67 

w 

Niqht  want  to  perform  control  total  checks 

prior  to  backup. 

55 

67 

A 

Restoration  would  have  to  meet  audit  checks. 

56 

57 

U 

Common  prep,  activities. 

56 

58 

w 

Data  format,  etc.,  common. 

56 

60 

N 

Entry  of  manual  proposals  must  lead  to 

Budget  Office  review. 

56 

74 

W 

Need  documentation  for  manual  entry. 

57 

58 

A 

Will  want  to  chack  on-line  preparation. 

57 

60 

W 

Common  on-line  processing. 

57 

74 

w 

On-line  activities  for  users  must  be  easy  to 

learn  and  teach. 

58 

59 

s 

Control  limits  key  to  automatic  checking. 

58 

60 

A 

Budget  Office  review  forms  part  of  check. 

58 

62 

A 

Check  sources  as  part  of  checking  procedures 

58 

6b 

4 

Check  that  category  codes  correct. 

58 

75 

A 

Adds  complexity  to  automatic  chocking 

funstion. 

57 

60 

A 

Review  aqainst  controlling  limits. 

59 

61 

A 

Review  changes  controlling  limits. 

59 

62 

A 

Controlling  limits  may  be  tied  to  S of  F. 

59 

63 

W 

Automatic  incrementation  in  employee 

benefits  requires  secondary  check. 

59 

65 

w 

Suspense  file  approach  tied  in  with 

controlling  limits. 
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59  68 

59  71 

59  75 

59  76 

60  61 
60  62 


60  65 


60  66 
60  68 
60  71 


61  62 
61  b3 


61  71 


62  71 


W There  arc  limits  on  such  items. 

S Commonality  in  performing  checks. 

A Control  limits  must  take  this  into  account, 

A Relevant  to  checking  overhead  amounts. 

A Common  review  mechanisms. 

S Sources  of  funding  important  aspect  of 
review. 

A OSP  can  use  same  mechanism  to  review 
research  proposals. 

W Would  have  to  check  categories. 

W Checking  overlap,  although  mainly  manual. 

A Budget  Office  must  be  able  to  review  these 
also  - common  facility  possible. 

A Chanqes  often  incorporate  new  funding. 

W Automatic  changes  make  change  review  more 
difficult  to  execute. 


6 1 

65 

A 

Nay 

need 

to  review  RP 

changes . 

61 

66 

W 

Nay 

need 

to  review  RP 

changes. 

61 

68 

A 

Changes 

to  budgeted  amounts  of  some 

62  65 


non-recurring  expenses  may  need  to  be 
reviewed . 

A Common  review  requirements  - potential 
common  facility. 

W S of  F data  related  to  research  proposal 
preparation. 

A Need  to  chack  fund  draft  against  account 
funded  to. 
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63  67  A Need  to  keep  audit  log  of  changes  to 

employer  benefits. 

63  75  S Automatic  changes  more  difficult  under  this 

reguirement . 

64  74  A Need  to  be  able  to  train  in  all  techniques. 

65  66  A Categorisation  information  part  of  data  base. 

65  76  A Overhead  rates  are  important  in  manipulation 

of  proposals. 

67  68  A Non-recurring  expense  transactions  must  be 

included  in  audit  trail. 

67  69  A Fund  drafts  must  be  included  in  audit  trail, 

67  70  A Fund  drafts  must  be  included  in  audit  trail. 

67  75  W Non-standard  employee  benefits  must  be 

auditable. 

67  76  H Overhead  recovery  rates  must  be  auditable. 

68  71  H Fund  drafts  for  most  non-recurring  expenses 

must  be  chacked. 

69  70  A Common  processing  issue. 

72  73  S Application  or  new  data  item  types. 


Appendix  F 

HE<JU1L t.lLNT  SUBSETS  DERIVED  FROM  THE  BEST  SYSTEK 

DECOHPOSITIGK. 


***  SUBPROBLEH  1 *** 


7.  Data  reqardinq  special  financial  arrangements  made 
by  manaqers  will  be  maintained. 

28.  Data  required  for  budqet  proposal  preparation  and 
not  available  elsewhere  will  be  maintained. 

38.  The  system  will  have  access  to  certain  personnel 
hirinq  data. 

56.  Budqet  proposals  can  be  prepared  manually. 

57.  Budqet  proposals  can  be  prepared  on-line. 

58.  Budqet  proposals  will  be  automatically  checked  and 
edited  to  the  extent  possible. 

59.  There  will  be  controlling  limits  on  amounts  in 
proposed  budqets  and  budqet  chanqes. 

60.  Budqet  proposals  will  be  reviewed  by  the  budget 
office  and/or  OSP. 

61.  Budqet  chanqes  will  be  reviewed  by  the  budget  off- 
ice and/or  OSP. 

62.  Sources  of  funding  for  each  account  will  be  iden- 
tified. 

65.  Research  proposal  information  can  be  stored, 
updated,  and  accessed. 

66.  Research  accounts  and  proposals  will  be  categor- 
ized by  type,  discipline,  and  function. 

68.  Required  aspects  of  non-recurring  expenses  will  be 
supported . 

71.  Fund  drafts  can  be  checked  and  approved  on-line  by 
Budqet  Office. 


133 


76.  Overhead  recovery  rate  calculations  vill  be  sup- 
ported. 


***  SUBPROBLEM  2 •** 


18.  There  will  be  a general  comparison  reporting  capa- 
bility. 

19.  Items  exceeding  prespecified  bounds  can  be  high- 
lighted. 

20.  Chart  of  Accounts  and  associated  supplementary 
data  vill  be  accessable  by  Budget  System. 

21.  Current  fiscal  year  budget  data  will  be  main- 

tained. 

22.  Future  Budget  data  vill  be  maintained. 

23.  Last  fiscal  yearv  Budget  data  vill  be  maintained. 

24.  Current  fiscal  year  Actual  data  vill  be  main- 

tained. 

25.  Last  fiscal  year  Actual  data  vill  be  maintained. 

26.  Historical  Budget  data  vill  be  maintained  for  up 
to  1 years. 

29.  Budgeted  income  and  expense  data  vill  be  prorated 
automatically  on  a month-by-month  basis. 

31.  Monitoring  of  the  operating  budget  will  be  sup- 
ported. 

32.  Various  Future  Budget  reports  vill  be  generated. 

33.  Periodic  operating  reports  for  each  account  will 
be  generated. 

34.  Various  special-purpose  (non-periodic)  reports 
vill  be  generated. 

36.  Ad  hoc  requests  for  information  vill  be  supported. 

39.  Certain  budqet  report  data  items  can  be  optionally 
included  or  excluded  from  Monthly  Analysis  Report 
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as  specified  by  the  user 


«0.  Variations  of  standard  Budget 
be  developed  as  requested. 


41.  Mew  budqet  reports  Kill  be  developed  as  reguired 

42.  There  will  be  a simple  report-writing  facility. 


***  SUBPROBLEtt  3 *** 


16.  Budgeting  and  planning  data  can  be  accessed  read 
ily  by  other  systems. 


43.  Users  can  develop  their  ow 
the  report  writing  facility 


44.  There  will  be  an  on-line  menu-oriented  query 
facility. 


45.  There  will  be  an  on-line  ad  hoc  query  facility 


Reports  generated  on-line  can  be  directed  to  the 
system  printer  or  to  users'  pri.iter/terminal. 


47.  Identity  and  activity  of  users  will  be  logged 


48.  Data  items  can  be  accessed 
users. 


49.  Data  items  can  be  changed  only  by  their  owner 


50.  There  will  be  a set 
data  item. 


51.  Each  data  item  will  have  a unique  owner 


52.  Data  items  can  be  encoded  for  security. 

64.  Ill  currently  used  budgeting  techniques  will  be 
supported. 


74.  Formal  training  in  the  use  of  the  system  will  be 
provided  to  users. 


***  SUBPROBLEH  4 *** 


15.  Reports  will  be  physically  easy  to  handle. 

77.  Standard  periodic  reports  will  be  produced  and 
distributed  to  users  as  guickly  as  possible. 


***  SUBPROBLEH  5 ♦** 

9.  Personnel  budgets  can  be  developed  in  EFT. 

10.  There  will  be  a facility  for  converting 
salary/wage  information  between  dollars  and  EFT. 

13.  Manpower  can  be  reported  in  alternative  units. 


***  SUBPROBLEH  6 *** 


53.  There  will  be  a log  of  all  database  changes. 

54.  There  will  be  a file  backup  facility. 

55.  The  database*s  integrity  can  be  restored  using 
backup  files  and  change  log  if  necessary. 

67.  There  will  be  documented  audit  trails  for  deter- 
mining system  discrepancies. 

69.  Fund  drafts  can  be  performed  on-line. 

70.  Fund  drafts  can  be  performed  in  batch  mode. 

***  SUBPROBLEH  7 *** 

logically  related  to  groups 
belong  to  multiple  object 
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14.  There  will  be  special  object  codes  available  for 
use  by  each  department. 


***  SOBPROBLEM  8 *** 


5.  Short-term  and  long-term  planning  data  will  be 
provided  by  Senior  Managers. 

6.  Planning  data  will  be  provided  in  a standardized 
format. 

27.  Historical  Actual  data  will  be  maintained  for  up 
to  1 years. 

35.  The  data  necessary  for  use  by  the  Dynamic  Model 
will  be  generated. 


*♦*  SOBPBOBLEM  9 *** 


8.  - Personnel  budgets  can  be  developed  in  dollars. 

63.  Budgeted  employee  benefits  will  be  changed  auto- 
matically following  changes  in  budgeted  salary  and 
waqe  amounts  or  EB  rates. 

75.  Non-standard  employee  benefit  calculations  will  be 
supported. 


***  SOBPROBLEH  10  **♦ 


1.  Fund  accounts  will  be  categorized  by  fund  pur- 
poses. 

2.  Fund  accounts  can  be  categorized  by  principal 
type. 

3.  Fund  accounts  can  be  categorized  by  income  type. 

4.  Each  fund  account  will  be  described  via  abbrevi- 
ated text  description. 
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17.  The  budget  system  can  access  directly  data  in 
other  systems*  files. 

30.  Information  to  facilitate  the  effective  use  of 
fund  accounts  vill  be  available. 

37.  Various  funds  reports  vill  be  generated. 

***  SOBPROBLEM  11  ♦** 

72.  Additional  data  item  types  can  be  added  to 
accounts  or  objects  vxthin  accounts. 


73.  Nev  data  items  can  include  or  refer  to  supplemen- 
tary data  needed  by  users. 


Ap Fendix  G 


INTERDEPENDENCIES  BETWEEN  REQUIREMENT  SUBSETS  IN  BEST 

DECOMPOSITION. 


CLUSTER  PAIR  INTERDEPENDENT  NODES 


1. 

2 

38, 

21  , A 

56, 

29, A 

58, 

20,  A 

58, 

24,  A 

60, 

21, A 

60, 

22,  A 

61, 

22,  A 

61. 

31,  A 

61, 

32,  W 

62, 

20, W 

62, 

21,  A 

62, 

22,  W 

62, 

29, A 

62, 

33, W 

65, 

22,  A 

65, 

40, W 

65, 

41,  A 

66, 

20,  W 

68, 

20,  W 

68, 

31, W 

1. 

3 

56, 

74, W 

57, 

74, W 

60, 

44,  A 

61, 

44, A 

71. 

44,  A 

i. 

4 

** 

NONE 

** 

1. 

5 

28, 

10, A 

38, 

9,« 

38. 

10,  W 

59, 

9,V 

1# 

6 

61. 

53, A 

68, 

67,  A 

76, 

67,  W 

1. 

7 

** 

NONE 

** 

1. 

8 

** 

NONE 

♦* 

1. 

9 

58. 

75, A 

59, 

63,  W 

59, 

75,  A 

61, 

63,  W 

1# 

10 

7, 

3, A 

7, 

30,  A 

7, 

37,  W 

58, 

1 , A 

60, 

1 » A 

62, 

30,  W 

62, 

37, A 

71, 

1,V 

71. 

17,  H 

71, 

30, A 

1. 

11 

** 

NONE 

** 

2, 

3 

29. 

48, W 

32, 

64,  W 

36, 

43,  A 

36, 

45, A 

36. 

48,  S 

42, 

43,  S 

«2, 

46,  W 

2, 

4 

** 

NONE 

** 

2.  5 


33,  9, A 


29,  9, A 
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2. 

6 

** 

NONE 

• * 

2. 

7 

34, 

11, A 

34, 

12, S 

2 , 

8 

18, 

27,  W 

20. 

35, A 

21, 

35,  H 

22, 

5,S 

22, 

6,W 

22, 

35,  A 

2 5, 

35, A 

34, 

5, A 

34, 

6,  B 

36, 

27,  K 

2, 

9 

22, 

63,  A 

29. 

8, A 

2. 

1C 

19. 

3, A 

20, 

1.A 

20, 

2,  A 

20, 

3,  A 

20, 

17, S 

20, 

37,  H 

21, 

30, S 

25, 

30,  V 

29. 

30,  S 

32, 

37, M 

33, 

37,  V 

36, 

1,  B 

36, 

2.W 

36, 

3, A 

36, 

4,  W 

36, 

3C  , A 

2. 

11 

20, 

72,  A 

20, 

73,  W 

36, 

72,  A 

39, 

72, W 

41. 

72, A 

3, 

4 

46, 

77, K 

3, 

5 

** 

NONE 

«* 

3. 

6 

47, 

53, A 

49, 

53, W 

3. 

7 

** 

NONE 

**• 

3. 

8 

** 

NONE 

** 

3. 

9 

*# 

NONE 

** 

3# 

10 

** 

NONE 

** 

3# 

11 

** 

NONE 

** 

4, 

5 

*♦ 

NONE 

*♦ 

**, 

6 

** 

NONE 

** 

4. 

7 

** 

NONE 

** 

4, 

8 

** 

NONE 

** 

4. 

9 

♦* 

NONE 

** 

4# 

10 

** 

NONE 

** 

4, 

11 

** 

NONE 

** 

5, 

6 

** 

NONE 

** 

5, 

7 

** 

NONE 

** 

5, 

8 

** 

NONE 

** 
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5. 

9 

10, 

a ,s 

13, 

8 , A 

5, 

10 

** 

NONE 

** 

5, 

1 1 

** 

NONE 

♦ * 

6, 

7 

** 

NONE 

** 

6, 

e 

*« 

NONE 

** 

6, 

9 

53, 

63,  V 

67, 

63,  A 

67,  75,  if 

6, 

10 

69, 

17, W 

69, 

30, A 

70,  30,  W 

6, 

ii 

53, 

72,  A 

7, 

8 

11, 

35,  A 

7, 

9 

** 

NONE 

** 

7# 

10 

** 

NONE 

** 

7, 

11 

♦* 

NONE 

** 

8, 

9 

** 

NONE 

** 

8, 

10 

** 

NONE 

** 

8, 

11 

** 

NONE 

** 

9, 

10 

** 

NONE 

** 

9, 

11 

** 

NONE 

♦* 

10, 

11 

1, 

72, S 

141 


